From jira-events at lists.jboss.org  Mon Jun  1 01:04:57 2009
From: jira-events at lists.jboss.org (Jeff Wexler (JIRA))
Date: Mon, 1 Jun 2009 01:04:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6333)
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <27205402.1229614674680.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4756351.1243832697063.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Wexler commented on JBAS-6333:
-----------------------------------

I am using 5.0.1.

The change to
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 

instead of 
<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends>

is still not in docs/examples/jms/postgresql-persistence-service.xml

I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors.

It appears from the comments of this jira issue that plans were to make this change to the persistence-service.xml scripts. If so, it would appear that this is still open.

> <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------
>
>                 Key: JBAS-6333
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6333
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.0.0.GA
>            Reporter: Clebert Suconic
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: JBossAS-5.1.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 01:07:15 2009
From: jira-events at lists.jboss.org (Jeff Wexler (JIRA))
Date: Mon, 1 Jun 2009 01:07:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6333)
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <27205402.1229614674680.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32125887.1243832835446.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Wexler commented on JBAS-6333:
-----------------------------------

Sorry typo in my comment above.
The version that I am using is 5.1.0.GA   (Not 5.0.1)

> <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------
>
>                 Key: JBAS-6333
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6333
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.0.0.GA
>            Reporter: Clebert Suconic
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: JBossAS-5.1.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 01:11:56 2009
From: jira-events at lists.jboss.org (Jeff Wexler (JIRA))
Date: Mon, 1 Jun 2009 01:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6991) Still issue in
 5.1.0.GA
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
Message-ID: <25176794.1243833116559.JavaMail.jira@cloud.prod.atl2.jboss.com>

Still issue in 5.1.0.GA <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
--------------------------------------------------------------------------------------------------------------

                 Key: JBAS-6991
                 URL: https://jira.jboss.org/jira/browse/JBAS-6991
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS (JBoss Messaging)
    Affects Versions: JBossAS-5.0.0.GA
            Reporter: Jeff Wexler
            Assignee: Howard Gao
            Priority: Minor
             Fix For: JBossAS-5.1.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 01:25:56 2009
From: jira-events at lists.jboss.org (Jeff Wexler (JIRA))
Date: Mon, 1 Jun 2009 01:25:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6991) Still issue in
 5.1.0.GA
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <25176794.1243833116559.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7225966.1243833956605.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Wexler updated JBAS-6991:
------------------------------

    Workaround Description: https://jira.jboss.org/jira/browse/JBAS-6333  (was: Change the depends attribute to a simple attribute:

it should be
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute>

instead of 

<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends>)
               Environment: Windows 2003 Server
         Affects Version/s: JBossAS-5.1.0.GA
                                (was: JBossAS-5.0.0.GA)
               Description: 
https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS-6333 was closed.

I recognize that I may have misunderstood the intentions of the developers on JBAS-6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.

I did not see how to re-open JBAS-6333 and thus am creating a new issue in jira.

The change to 
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 

instead of 
<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 

is still not in docs/examples/jms/postgresql-persistence-service.xml 

I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 



> Still issue in 5.1.0.GA <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6991
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6991
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows 2003 Server
>            Reporter: Jeff Wexler
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: JBossAS-5.1.0.Beta1
>
>
> https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS-6333 was closed.
> I recognize that I may have misunderstood the intentions of the developers on JBAS-6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.
> I did not see how to re-open JBAS-6333 and thus am creating a new issue in jira.
> The change to 
> <attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 
> instead of 
> <depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 
> is still not in docs/examples/jms/postgresql-persistence-service.xml 
> I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 01:27:56 2009
From: jira-events at lists.jboss.org (Jeff Wexler (JIRA))
Date: Mon, 1 Jun 2009 01:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6991) Still issue in
 5.1.0.GA
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <25176794.1243833116559.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13261367.1243834076669.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Wexler updated JBAS-6991:
------------------------------

    Fix Version/s:     (was: JBossAS-5.1.0.Beta1)


> Still issue in 5.1.0.GA <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6991
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6991
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows 2003 Server
>            Reporter: Jeff Wexler
>            Assignee: Howard Gao
>            Priority: Minor
>
> https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS-6333 was closed.
> I recognize that I may have misunderstood the intentions of the developers on JBAS-6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.
> I did not see how to re-open JBAS-6333 and thus am creating a new issue in jira.
> The change to 
> <attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 
> instead of 
> <depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 
> is still not in docs/examples/jms/postgresql-persistence-service.xml 
> I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 01:27:56 2009
From: jira-events at lists.jboss.org (Jeff Wexler (JIRA))
Date: Mon, 1 Jun 2009 01:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6991) Still issue in
 5.1.0.GA
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <25176794.1243833116559.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30082493.1243834076825.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Wexler updated JBAS-6991:
------------------------------

    Description: 
https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS - 6333 was closed.

I recognize that I may have misunderstood the intentions of the developers on JBAS - 6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.

I did not see how to re-open JBAS - 6333 and thus am creating a new issue in jira.

The change to 
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 

instead of 
<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 

is still not in docs/examples/jms/postgresql-persistence-service.xml 

I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 


  was:
https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS-6333 was closed.

I recognize that I may have misunderstood the intentions of the developers on JBAS-6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.

I did not see how to re-open JBAS-6333 and thus am creating a new issue in jira.

The change to 
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 

instead of 
<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 

is still not in docs/examples/jms/postgresql-persistence-service.xml 

I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 




> Still issue in 5.1.0.GA <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6991
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6991
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows 2003 Server
>            Reporter: Jeff Wexler
>            Assignee: Howard Gao
>            Priority: Minor
>
> https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS - 6333 was closed.
> I recognize that I may have misunderstood the intentions of the developers on JBAS - 6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.
> I did not see how to re-open JBAS - 6333 and thus am creating a new issue in jira.
> The change to 
> <attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 
> instead of 
> <depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 
> is still not in docs/examples/jms/postgresql-persistence-service.xml 
> I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 02:33:56 2009
From: jira-events at lists.jboss.org (Jeff Wexler (JIRA))
Date: Mon, 1 Jun 2009 02:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6991) Still issue in
 5.1.0.GA
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <25176794.1243833116559.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9022439.1243838036577.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Wexler updated JBAS-6991:
------------------------------

    Description: 
https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS - 6333 was closed.

I recognize that I may have misunderstood the intentions of the developers on JBAS - 6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.

I did not see how to re-open JBAS - 6333 and thus am creating a new issue in jira.

The change to 
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 

instead of 
<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 

is still not in docs/examples/jms/postgresql-persistence-service.xml 

I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 

However, other encountered other messaging errors when running the booking example using postgresql and thus commented out the attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory statement.

Perhaps, this statement should be commented out in the original <database>-persistence-service.xml files?

  was:
https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS - 6333 was closed.

I recognize that I may have misunderstood the intentions of the developers on JBAS - 6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.

I did not see how to re-open JBAS - 6333 and thus am creating a new issue in jira.

The change to 
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 

instead of 
<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 

is still not in docs/examples/jms/postgresql-persistence-service.xml 

I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 




> Still issue in 5.1.0.GA <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6991
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6991
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows 2003 Server
>            Reporter: Jeff Wexler
>            Assignee: Howard Gao
>            Priority: Minor
>
> https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS - 6333 was closed.
> I recognize that I may have misunderstood the intentions of the developers on JBAS - 6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.
> I did not see how to re-open JBAS - 6333 and thus am creating a new issue in jira.
> The change to 
> <attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 
> instead of 
> <depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 
> is still not in docs/examples/jms/postgresql-persistence-service.xml 
> I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 
> However, other encountered other messaging errors when running the booking example using postgresql and thus commented out the attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory statement.
> Perhaps, this statement should be commented out in the original <database>-persistence-service.xml files?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 02:55:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 1 Jun 2009 02:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6991) Still issue in
 5.1.0.GA
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <25176794.1243833116559.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6309096.1243839356475.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBAS-6991:
----------------------------------

Hi Jeff,

Are you saying that even you have made the change, you still have other errors? If so, what are they?

Thanks,
Howard


> Still issue in 5.1.0.GA <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6991
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6991
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows 2003 Server
>            Reporter: Jeff Wexler
>            Assignee: Howard Gao
>            Priority: Minor
>
> https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS - 6333 was closed.
> I recognize that I may have misunderstood the intentions of the developers on JBAS - 6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.
> I did not see how to re-open JBAS - 6333 and thus am creating a new issue in jira.
> The change to 
> <attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 
> instead of 
> <depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 
> is still not in docs/examples/jms/postgresql-persistence-service.xml 
> I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 
> However, other encountered other messaging errors when running the booking example using postgresql and thus commented out the attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory statement.
> Perhaps, this statement should be commented out in the original <database>-persistence-service.xml files?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 03:02:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 1 Jun 2009 03:02:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (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: <25230422.1243839777112.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao reassigned JBMESSAGING-1631:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>         Attachments: logs-and-config-prod.zip, logs-and-config-test.zip
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 03:04:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 1 Jun 2009 03:04:56 -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: <6515510.1243839896659.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao updated JBMESSAGING-1631:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: logs-and-config-prod.zip, logs-and-config-test.zip
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 03:21:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 1 Jun 2009 03:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6333)
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <27205402.1229614674680.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31317725.1243840916610.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBAS-6333:
----------------------------------

The changes has not been made to AS 5 repository.

As Jeff already created another issue for that. I will not re-open it. 

> <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------
>
>                 Key: JBAS-6333
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6333
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.0.0.GA
>            Reporter: Clebert Suconic
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: JBossAS-5.1.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 04:28:56 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Mon, 1 Jun 2009 04:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Admin Join problem
 -GMS flush by coordinator failed
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4748314.1243844936585.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Vladimir Blagojevic commented on JGRP-985:
------------------------------------------

I've looked through this example and I am not sure about the following. First, why did you comment out UNICAST protocol? In tests like this one use a default udp.xml stack provided in distribution. Second, why are you getting state if there is no state in application, you do not implement state installation callbacks? 



> Admin  Join problem -GMS flush by coordinator failed
> ----------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 05:02:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 1 Jun 2009 05:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <1097617.1243846976786.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1631:
-----------------------------------------

Hi Victor,

Do you have a test MDB for the issue? I'm trying to make a test to reproduce it. Thanks.

Howard


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: logs-and-config-prod.zip, logs-and-config-test.zip
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 06:24:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 1 Jun 2009 06:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1840) StrictMaxPool
 does not
 maintain a correct "inUse" count leading to incorrect reporting of
 "AvailableCount"
Message-ID: <742346.1243851896474.JavaMail.jira@cloud.prod.atl2.jboss.com>

StrictMaxPool does not maintain a correct "inUse" count leading to incorrect reporting of "AvailableCount"
----------------------------------------------------------------------------------------------------------

                 Key: EJBTHREE-1840
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1840
             Project: EJB 3.0
          Issue Type: Bug
          Components: pool
    Affects Versions: 1.1.6
            Reporter: jaikiran pai
            Assignee: jaikiran pai
             Fix For: 1.1.7


The org.jboss.ejb3.test.stateless.unit.MetricsUnitTestCase shows a failure w.r.t the "AvailableCount" of a bean marked with StrictMaxPool. 

The StrictMaxPool internally implements the getAvailableCount() as follows:

   public int getAvailableCount()
   {
      return maxSize - inUse;
   }


The "inUse" count is handled incorrectly in the discard and remove method of this pool leading to that count reaching a negative value. Ultimately, this leads to incorrect available count being reported.

When an exception occurs, the bean is discarded from the pool. This leads to a call on discard method of the StrictMaxPool which decrements the inUse count and then calls the remove method which *again* decrements the inUse count for the same bean context.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 06:31:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 1 Jun 2009 06:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1840) StrictMaxPool
 does not
 maintain a correct "inUse" count leading to incorrect reporting of
 "AvailableCount"
In-Reply-To: <742346.1243851896474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29602325.1243852316434.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai updated EJBTHREE-1840:
-----------------------------------

    Component/s: core
                     (was: pool)


> StrictMaxPool does not maintain a correct "inUse" count leading to incorrect reporting of "AvailableCount"
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1840
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1840
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.6
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> The org.jboss.ejb3.test.stateless.unit.MetricsUnitTestCase shows a failure w.r.t the "AvailableCount" of a bean marked with StrictMaxPool. 
> The StrictMaxPool internally implements the getAvailableCount() as follows:
>    public int getAvailableCount()
>    {
>       return maxSize - inUse;
>    }
> The "inUse" count is handled incorrectly in the discard and remove method of this pool leading to that count reaching a negative value. Ultimately, this leads to incorrect available count being reported.
> When an exception occurs, the bean is discarded from the pool. This leads to a call on discard method of the StrictMaxPool which decrements the inUse count and then calls the remove method which *again* decrements the inUse count for the same bean context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 07:56:56 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 1 Jun 2009 07:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6992) Missing new line in
 MANIFEST.MF cause deployment to fail
Message-ID: <20895033.1243857416511.JavaMail.jira@cloud.prod.atl2.jboss.com>

Missing new line in MANIFEST.MF cause deployment to fail
--------------------------------------------------------

                 Key: JBAS-6992
                 URL: https://jira.jboss.org/jira/browse/JBAS-6992
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployers
    Affects Versions: JBossAS-5.1.0.GA
         Environment: WinXP, jdk 1.6.0u13
            Reporter: Ondrej Medek
            Assignee: Ales Justin


Hi,
I have an exploded EAR, it contains one JAR with session beans. This JAR has the MANIFEST.MF, with Class-Path entry referencing two more JARs (plain JARs, not beans). Whe this Class-Path entry not finished by a new line character, then deployment fails du to the java.lang.ClassNotFoundException. When I have added the new line anfter the Class-Path entry, then everything goes fine.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 08:00:56 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 1 Jun 2009 08:00:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6992) Missing new line in
 MANIFEST.MF cause deployment to fail
In-Reply-To: <20895033.1243857416511.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27614628.1243857656993.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ondrej Medek updated JBAS-6992:
-------------------------------

    Attachment: doNothing.ear


Just deploy this file. (Stolen from https://jira.jboss.org/jira/browse/JBAS-6518 and then modified.)

> Missing new line in MANIFEST.MF cause deployment to fail
> --------------------------------------------------------
>
>                 Key: JBAS-6992
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6992
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: WinXP, jdk 1.6.0u13
>            Reporter: Ondrej Medek
>            Assignee: Ales Justin
>         Attachments: doNothing.ear
>
>
> Hi,
> I have an exploded EAR, it contains one JAR with session beans. This JAR has the MANIFEST.MF, with Class-Path entry referencing two more JARs (plain JARs, not beans). Whe this Class-Path entry not finished by a new line character, then deployment fails du to the java.lang.ClassNotFoundException. When I have added the new line anfter the Class-Path entry, then everything goes fine.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 09:16:56 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 1 Jun 2009 09:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6993)
 jboss-main-client.jar is empty in JBoss 5.1.0GA
Message-ID: <20312495.1243862216771.JavaMail.jira@cloud.prod.atl2.jboss.com>

jboss-main-client.jar is empty in JBoss 5.1.0GA
-----------------------------------------------

                 Key: JBAS-6993
                 URL: https://jira.jboss.org/jira/browse/JBAS-6993
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ondrej Medek
            Priority: Optional


May it be removed?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 09:18:56 2009
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 1 Jun 2009 09:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6993)
 jboss-main-client.jar is empty in JBoss 5.1.0GA
In-Reply-To: <20312495.1243862216771.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32381338.1243862336626.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Dimitris Andreadis reassigned JBAS-6993:
----------------------------------------

    Assignee: Paul Gier


> jboss-main-client.jar is empty in JBoss 5.1.0GA
> -----------------------------------------------
>
>                 Key: JBAS-6993
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6993
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ondrej Medek
>            Assignee: Paul Gier
>            Priority: Optional
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> May it be removed?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 09:18:56 2009
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 1 Jun 2009 09:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6993)
 jboss-main-client.jar is empty in JBoss 5.1.0GA
In-Reply-To: <20312495.1243862216771.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5913374.1243862336824.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Dimitris Andreadis updated JBAS-6993:
-------------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> jboss-main-client.jar is empty in JBoss 5.1.0GA
> -----------------------------------------------
>
>                 Key: JBAS-6993
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6993
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ondrej Medek
>            Assignee: Paul Gier
>            Priority: Optional
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> May it be removed?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 09:32:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 1 Jun 2009 09:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBJCA-29) Testing of JCA xml
	parsing
In-Reply-To: <1681691.1215677367200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4482075.1243863176952.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Zhang closed JBJCA-29.
---------------------------

    Fix Version/s: 1.0.0.Alpha1
       Resolution: Done


see JIRA in Metadata project
https://jira.jboss.org/jira/browse/JBMETA-111
https://jira.jboss.org/jira/browse/JBMETA-158

> Testing of JCA xml parsing
> --------------------------
>
>                 Key: JBJCA-29
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-29
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Adrian Brock
>            Assignee: Jeff Zhang
>            Priority: Minor
>             Fix For: 1.0.0.Alpha1
>
>
> As JBAS-5715 shows (and some earlier problems with the new -ds.xml parsing), 
> the testing of the JCA xml parsing is woefully incomplete in terms of catching regressions.
> There should be systematic tests for each element of ra.xml, jboss-ra.xml, -ds.xml
> * To catch future bugs introduced in the parsing
> * To make sure invalid values are being correctly rejected
> * The xml values are making it through to the artifacts (currently mbeans) in the backend

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 09:34:57 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 1 Jun 2009 09:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBJCA-47) remove compile
 warning and checkstyle error
In-Reply-To: <2619941.1236819880117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13768064.1243863297015.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Zhang commented on JBJCA-47:
---------------------------------

we have only two checkstyle warning by JCA API code

[checkstyle] api/src/main/java/javax/resource/spi/Activation.java:64: Unused Javadoc tag.
[checkstyle] api/src/main/java/javax/resource/spi/ConnectionDefinitions.java:51: Unused Javadoc tag.


> remove compile warning and checkstyle error
> -------------------------------------------
>
>                 Key: JBJCA-47
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-47
>             Project: JBoss JCA
>          Issue Type: Sub-task
>          Components: Build
>    Affects Versions: 1.0.0.Alpha1
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha1
>
>
> We use this JIRA to track compile waring removing and fix checkstyle error message

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 09:36:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 1 Jun 2009 09:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-47) remove compile
 warning and checkstyle error
In-Reply-To: <2619941.1236819880117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33507136.1243863416884.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Zhang resolved JBJCA-47.
-----------------------------

    Resolution: Done


> remove compile warning and checkstyle error
> -------------------------------------------
>
>                 Key: JBJCA-47
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-47
>             Project: JBoss JCA
>          Issue Type: Sub-task
>          Components: Build
>    Affects Versions: 1.0.0.Alpha1
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha1
>
>
> We use this JIRA to track compile waring removing and fix checkstyle error message

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 10:29:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 1 Jun 2009 10:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2392) Selenium tests
	for XSS
In-Reply-To: <23069268.1242226847011.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31998028.1243866596504.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470091#action_12470091 ] 

Viliam Rockai commented on JBPORTAL-2392:
-----------------------------------------

since the selenium has troubles with testing the appearance of unexpected alert i will implement these test in a different way. i'll add  inputa validation test methods to my existing tests. Submitting an XSS string should lead into error message about invalid input.

> Selenium tests for XSS
> ----------------------
>
>                 Key: JBPORTAL-2392
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2392
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal QA
>            Reporter: Viliam Rockai
>            Assignee: Viliam Rockai
>
> Testing XSS on inputs in portal GUI had to be implemented.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 10:37:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 1 Jun 2009 10:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2309) end to end
 admin test for adding new portal
In-Reply-To: <20849835.1234456125221.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22220820.1243867076510.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470092#action_12470092 ] 

Viliam Rockai commented on JBPORTAL-2309:
-----------------------------------------

i have implemented most of the phase II, but i still have few questions:

- adding a listener
how can I verify that a listener was successfully added? my current test adds a listener, then reloads a page and verifies that the listener is currently selected. no deeper logic is tested.

- error handling
this is a tricky one. i can verify that previously selected values are selected, but i guess it is not enough.

any quick ideas where can i find (so i can successfully test it) these cases?
for portal:
When the page is unavailable
When there is an error within the page
When the page is not found

for page:
When the window is unavailable 
When there is an error within the window 	
When the window is not found 




> end to end admin test for adding new portal
> -------------------------------------------
>
>                 Key: JBPORTAL-2309
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2309
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>
> As an admin,
> Portal Creation:
> Priority I:
> - create a new portal
> - add couple of page to the portal
> - add few portlets of different kinds (csm, widget, regular portlets) in each page
> - verify that new portal, pages and portlets get added correctly.
> - Make the new portal default and verify that it becomes default portal
> Priority II:
> Click on Properties under Manage Portals link
> - Verify that you can add listener
> - Different properties (dnd, partial refresh)
> - Modify error handling 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 10:41:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 1 Jun 2009 10:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6987) Disable registering
 of MC bean components as MBeans by default
In-Reply-To: <15432287.1243512657033.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25585179.1243867316591.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai resolved JBAS-6987.
--------------------------------

    Resolution: Done


Done in r89605.

> Disable registering of MC bean components as MBeans by default
> --------------------------------------------------------------
>
>                 Key: JBAS-6987
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6987
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Every MC bean that gets deployed, also gets registered as a MBean. These MBeans are optional and only provide debug information. These can by default be disabled. Refer to the referenced forum thread for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 10:51:08 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 10:51:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-6619) warnings seen during
 startup with console when populating JMS queue managed objects
In-Reply-To: <2036778.1236960202463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13171709.1243867868445.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer closed JBAS-6619.
------------------------------



> warnings seen during startup with console when populating JMS queue managed objects
> -----------------------------------------------------------------------------------
>
>                 Key: JBAS-6619
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6619
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-5.1.0.Beta1
>         Environment: r85733
>            Reporter: Charles Crouch
>            Assignee: Scott M Stark
>            Priority: Optional
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> In the server log during start up I'm seeing these warnings
> 2009-03-13 10:40:35,484 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Created name: vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml from property: name
> 2009-03-13 10:40:35,484 DEBUG [org.jboss.jms.server.destination.QueueMODefinition] (ResourceContainer.invoker.daemon-3) Creating QueueServiceMO template for: class org.jboss.jms.server.destination.QueueService
> 2009-03-13 10:40:35,515 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) ManagedObject(org.jboss.jms.server.destination.QueueServiceMO) is ManagedComponent type: @org.jboss.managed.api.annotation.ManagementComponent(type=JMSDestination, subtype=Queue)
> 2009-03-13 10:40:35,515 WARN  [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 2009-03-13 10:40:35,515 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) Created skeleton ManagedObject: ManagedObject{org.jboss.jms.server.destination.QueueServiceMO}
> 2009-03-13 10:40:35,515 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Created name: /queue/DLQ from property: JNDIName
> 2009-03-13 10:40:35,531 DEBUG [org.jboss.jms.server.destination.QueueMODefinition] (ResourceContainer.invoker.daemon-3) Creating QueueServiceMO template for: class org.jboss.jms.server.destination.QueueService
> 2009-03-13 10:40:35,531 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) ManagedObject(org.jboss.jms.server.destination.QueueServiceMO) is ManagedComponent type: @org.jboss.managed.api.annotation.ManagementComponent(type=JMSDestination, subtype=Queue)
> 2009-03-13 10:40:35,531 WARN  [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 2009-03-13 10:40:35,531 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) Created skeleton ManagedObject: ManagedObject{org.jboss.jms.server.destination.QueueServiceMO}
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Created name: /queue/ExpiryQueue from property: JNDIName
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) ID for ManagedObject: vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment, attachmentName: org.jboss.system.metadata.ServiceDeployment
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) checkForReferences, vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment has referers: null
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) Checking property: ManagedProperty{classpath,classPaths,metaType=CollectionMetaType{type=java.util.List elementType=GenericMetaType:org.jboss.managed.api.ManagedObject}
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) Checking property: ManagedProperty{name,name,metaType=SimpleMetaType:java.lang.String}
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) ManagedProperty level ID for ManagedObject: vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment, attachmentName: org.jboss.system.metadata.ServiceDeployment
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) checkForReferences, vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment has referers: null

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 10:51:07 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 10:51:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6833) warnings from
 AbstractManagedObjectPopulator printed when ManagementView.load() is called
In-Reply-To: <6769558.1240600726809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2155391.1243867867657.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6833:
-------------------------------

        Fix Version/s: JBossAS-5.2.0.Beta1
    Affects Version/s: JBossAS-5.1.0.GA


> warnings from AbstractManagedObjectPopulator printed when ManagementView.load() is called
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-6833
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6833
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When I call ManagementView.load() , I see the following warnings in the log. They don't seem to cause any harm, but it would be good to fix whatever the underlying cause is, so they don't freak out users and waste space in the log.
> 14:10:03,459 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 14:10:04,318 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 14:10:04,334 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 14:10:04,662 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 10:51:08 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 10:51:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6619) warnings seen
 during startup
 with console when populating JMS queue managed objects
In-Reply-To: <2036778.1236960202463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5983570.1243867868277.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer resolved JBAS-6619.
--------------------------------

    Resolution: Duplicate Issue


Dup of JBAS-6833.


> warnings seen during startup with console when populating JMS queue managed objects
> -----------------------------------------------------------------------------------
>
>                 Key: JBAS-6619
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6619
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-5.1.0.Beta1
>         Environment: r85733
>            Reporter: Charles Crouch
>            Assignee: Scott M Stark
>            Priority: Optional
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> In the server log during start up I'm seeing these warnings
> 2009-03-13 10:40:35,484 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Created name: vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml from property: name
> 2009-03-13 10:40:35,484 DEBUG [org.jboss.jms.server.destination.QueueMODefinition] (ResourceContainer.invoker.daemon-3) Creating QueueServiceMO template for: class org.jboss.jms.server.destination.QueueService
> 2009-03-13 10:40:35,515 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) ManagedObject(org.jboss.jms.server.destination.QueueServiceMO) is ManagedComponent type: @org.jboss.managed.api.annotation.ManagementComponent(type=JMSDestination, subtype=Queue)
> 2009-03-13 10:40:35,515 WARN  [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 2009-03-13 10:40:35,515 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) Created skeleton ManagedObject: ManagedObject{org.jboss.jms.server.destination.QueueServiceMO}
> 2009-03-13 10:40:35,515 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Created name: /queue/DLQ from property: JNDIName
> 2009-03-13 10:40:35,531 DEBUG [org.jboss.jms.server.destination.QueueMODefinition] (ResourceContainer.invoker.daemon-3) Creating QueueServiceMO template for: class org.jboss.jms.server.destination.QueueService
> 2009-03-13 10:40:35,531 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) ManagedObject(org.jboss.jms.server.destination.QueueServiceMO) is ManagedComponent type: @org.jboss.managed.api.annotation.ManagementComponent(type=JMSDestination, subtype=Queue)
> 2009-03-13 10:40:35,531 WARN  [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 2009-03-13 10:40:35,531 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) Created skeleton ManagedObject: ManagedObject{org.jboss.jms.server.destination.QueueServiceMO}
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Created name: /queue/ExpiryQueue from property: JNDIName
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) ID for ManagedObject: vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment, attachmentName: org.jboss.system.metadata.ServiceDeployment
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) checkForReferences, vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment has referers: null
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) Checking property: ManagedProperty{classpath,classPaths,metaType=CollectionMetaType{type=java.util.List elementType=GenericMetaType:org.jboss.managed.api.ManagedObject}
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) Checking property: ManagedProperty{name,name,metaType=SimpleMetaType:java.lang.String}
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) ManagedProperty level ID for ManagedObject: vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment, attachmentName: org.jboss.system.metadata.ServiceDeployment
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) checkForReferences, vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment has referers: null

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 10:52:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 10:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6817) Add isNullable
 attribute to ManagedParameter interface
In-Reply-To: <22678848.1240427615790.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29552528.1243867976790.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6817:
-------------------------------

        Fix Version/s: JBossAS-5.2.0.Beta1
    Affects Version/s: JBossAS-5.1.0.GA
             Assignee: Emanuel Muckenhuber


> Add isNullable attribute to ManagedParameter interface
> ------------------------------------------------------
>
>                 Key: JBAS-6817
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6817
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Charles Crouch
>            Assignee: Emanuel Muckenhuber
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> See comments on JBAS-6686 for more details

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 11:15:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 11:15:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6769) 'interleaving'
 prop on connection factories and datasources has no ViewUse
In-Reply-To: <25774147.1239372696724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6895441.1243869356654.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer commented on JBAS-6769:
------------------------------------

This issue still exists as of r89598.


> 'interleaving' prop on connection factories and datasources has no ViewUse
> --------------------------------------------------------------------------
>
>                 Key: JBAS-6769
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6769
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Minor
>
> name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 11:18:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 11:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6769) 'interleaving' prop
 on connection factories and datasources has no ViewUse
In-Reply-To: <25774147.1239372696724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10965726.1243869536967.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6769:
-------------------------------

    Affects Version/s: JBossAS-5.1.0.GA


> 'interleaving' prop on connection factories and datasources has no ViewUse
> --------------------------------------------------------------------------
>
>                 Key: JBAS-6769
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6769
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Minor
>
> name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 11:22:56 2009
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Mon, 1 Jun 2009 11:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2309) end to end
 admin test for adding new portal
In-Reply-To: <20849835.1234456125221.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19522296.1243869776795.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470107#action_12470107 ] 

Prabhat Jha commented on JBPORTAL-2309:
---------------------------------------

What you have so far is good. 

To test the scenario where your custom error file is being used, you would have to simulate that. I think easier way would be to Hit a wrong URL with portal which is not there and asset on the page that you are getting. It should show your custom error message page. 

For listener, I would have to think. Let me get back to you on this.



> end to end admin test for adding new portal
> -------------------------------------------
>
>                 Key: JBPORTAL-2309
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2309
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>
> As an admin,
> Portal Creation:
> Priority I:
> - create a new portal
> - add couple of page to the portal
> - add few portlets of different kinds (csm, widget, regular portlets) in each page
> - verify that new portal, pages and portlets get added correctly.
> - Make the new portal default and verify that it becomes default portal
> Priority II:
> Click on Properties under Manage Portals link
> - Verify that you can add listener
> - Different properties (dnd, partial refresh)
> - Modify error handling 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 11:28:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 1 Jun 2009 11:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1633)
 MessageRedistribution example fails
In-Reply-To: <19879086.1243422057886.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8032592.1243870136563.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox closed JBMESSAGING-1633.
--------------------------------

    Resolution: Done


> MessageRedistribution example fails
> -----------------------------------
>
>                 Key: JBMESSAGING-1633
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1633
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0 Beta
>
>
> MessageRedistribution example fails especially after doing an ant clean first. Might be intermittent.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 14:43:56 2009
From: jira-events at lists.jboss.org (Steven Crosley (JIRA))
Date: Mon, 1 Jun 2009 14:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2405) dyna.js attaches
 observer to all draggable objects
Message-ID: <23488647.1243881836546.JavaMail.jira@cloud.prod.atl2.jboss.com>

dyna.js attaches observer to all draggable objects
--------------------------------------------------

                 Key: JBPORTAL-2405
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2405
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Web
    Affects Versions: 2.7.1 Final
         Environment: OS X, Safari 3.2.1, JBoss Portal 2.7.1
            Reporter: Steven Crosley


When using Scriptaculous' Sortables functionality within a portlet, I am getting an alert message "Error 500 -- OK".

I believe the issue is that in dyna.js an observer is placed on ALL draggable objects:

Draggables.addObserver(new WindowMoveObserver());

This attempts to update the database with the portlet's region even if the DnD exists inside of a portlet.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 15:16:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 15:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6824)
 DeploymentManager.start/stop()
 fail with NoSuchDeploymentException when called on a Deployment that is a
 child of another Deployment
In-Reply-To: <29702918.1240518760377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4488113.1243883817064.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6824:
-------------------------------

        Fix Version/s: JBossAS-5.2.0.Beta1
    Affects Version/s: JBossAS-5.1.0.GA
             Priority: Minor  (was: Major)


> DeploymentManager.start/stop() fail with NoSuchDeploymentException when called on a Deployment that is a child of another Deployment
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6824
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6824
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Emanuel Muckenhuber
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> For example:
> 16:29:47,528 INFO  [DeployHandler] Stop, [vfsfile:/C:/opt/jboss-5.1.0.CR1-SNAPSHOT/server/default/deploy/jbossws.sar/jbossws-management.war/]
> 16:29:47,528 INFO  [DeployHandler] Failed to complete command: [stop] for deployment: names=[vfsfile:/C:/opt/jboss-5.1.0.CR1-SNAPSHOT/server/default/deploy/jbos
> sws.sar/jbossws-management.war/], copyContent=true
> org.jboss.profileservice.spi.NoSuchDeploymentException: Failed to find deployment in file: vfsfile:/C:/opt/jboss-5.1.0.CR1-SNAPSHOT/server/default/deploy/jbossw
> s.sar/jbossws-management.war/
>         at org.jboss.system.server.profileservice.repository.AbstractDeploymentRepository.getDeployment(AbstractDeploymentRepository.java:134)
>         at org.jboss.profileservice.management.upload.remoting.DeployHandler.scheduleStop(DeployHandler.java:156)
>         at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.stop(AbstractDeployHandler.java:307)
>         at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.stop(AbstractDeployHandler.java:296)
>         at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:181)
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:305)
>         at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.stop(StreamingDeploymentTarget.java:208)
>         at org.jboss.profileservice.management.upload.DeploymentProgressImpl.stop(DeploymentProgressImpl.java:276)
>         at org.jboss.profileservice.management.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:91)
>         at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:97)
>         at org.rhq.plugins.jbossas5.ManagedDeploymentComponent.invokeOperation(ManagedDeploymentComponent.java:129)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:484)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 15:20:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Mon, 1 Jun 2009 15:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-413)
 "security-config.dtd" and
 xsd got lost in JBoss5 binaries and at the schema location
In-Reply-To: <20395249.1243450809953.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9238871.1243884056520.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Wolfgang Knauf commented on SECURITY-413:
-----------------------------------------

Same problem came up in the comments of this wiki article: http://www.jboss.org/community/wiki/JBossDTDs

> "security-config.dtd" and xsd got lost in JBoss5 binaries and at the schema location
> ------------------------------------------------------------------------------------
>
>                 Key: SECURITY-413
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-413
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Wolfgang Knauf
>            Assignee: Anil Saldhana
>
> JBoss 4.2.x contains "security-config.dtd" in the "docs/dtd" directory, but in 5.x the file is lost. Same for "security-config_4_0.xsd" and "security-config_4_1.xsd" in "docs/schema"
> Seems to be a result of the file being moved to a different project: https://jira.jboss.org/jira/browse/SECURITY-260
> Also, the file (and also the schemas) is no longer found at http://www.jboss.org/j2ee/dtd/security-config.dtd (which should be the schema location), came up here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=155436
> This prevents validation of "login-config.xml" files, if they are editing using e.g. Eclipse.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 15:18:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 15:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-6818) Invoking the "List All
 Subscriptions" operation from the embedded console for a Topic that has
 multiple subscribers results in an empty list being displayed
Message-ID: <24082908.1243883936597.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer closed JBAS-6818.
------------------------------



> Invoking the "List All Subscriptions" operation from the embedded console for a Topic that has multiple subscribers results in an empty list being displayed
> ------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6818
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6818
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r86689, embjopr r269
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Steps to reproduce:
> Create a new Topic. Create multiple subscribers for that Topic. Invoke the "List All Subscriptions" operation. Click on the "Show/Hide Details" link in the operations history table. The following gets displayed in the "Results" section:
> Viewing/editing of lists of PropertyDefinitionSimple properties is not yet supported. Here's the list's toString() value for now: []

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 17:20:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 1 Jun 2009 17:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1839) Implement
 POJO-based, @ManagedObject Session Metrics
In-Reply-To: <32587729.1243384676916.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9197649.1243891256733.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger updated EJBTHREE-1839:
------------------------------------------

    Component/s:     (was: core)
                     (was: metrics-spi)


> Implement POJO-based, @ManagedObject Session Metrics
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1839
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1839
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: metrics-deployer
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.7
>
>         Attachments: metrics.patch
>
>
> Defined by JBAS-6624.
> Consoles need Statistics accessible via ProfileService and jboss-management @ManagedObjects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 17:33:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 17:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS destinations
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23476947.1243892036802.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6783:
-------------------------------

    Summary: NPE when setting 'messageCounterHistoryDayLimit' prop on JMS destinations  (was: Allow messageCounterHistoryDayLimit to be set on JMS destinations)


> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS destinations
> -------------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Reporting this on behalf of Emanuel.
> See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 for his original comments.
> In todays meeting he mentioned you get an NPE when setting the messageCounterHistoryDayLimit  property.
> More investigation is needed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 17:41:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 17:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS destinations
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18311496.1243892516464.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6783:
-------------------------------

    Labels: EmbJopr1_3  (was: )


> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS destinations
> -------------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Reporting this on behalf of Emanuel.
> See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 for his original comments.
> In todays meeting he mentioned you get an NPE when setting the messageCounterHistoryDayLimit  property.
> More investigation is needed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 17:43:56 2009
From: jira-events at lists.jboss.org (Ben Abernathy (JIRA))
Date: Mon, 1 Jun 2009 17:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6932) Sample
 applications can't be found at JBOSS_HOME/docs/examples folder
In-Reply-To: <15062775.1242504485494.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6847673.1243892636471.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ben Abernathy commented on JBAS-6932:
-------------------------------------

Add 5.0.0.GA and 5.1.0.GA to the list.

> Sample applications can't be found at JBOSS_HOME/docs/examples folder
> ---------------------------------------------------------------------
>
>                 Key: JBAS-6932
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6932
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Docs/Installation and Getting Started Guide
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: JBossAS-5.0.1.GA-jdk6.zip
>            Reporter: Richard Yin
>
> In chapter 11, it says:
>  The JBoss Application Server, ships with various sample applications under JBOSS_HOME/docs/examples.
> For further details, please refer to the accompanying readme.txt for the respective sample applications under the above directory. 
> I can't find any referred applications in this folder, nor the readme.txt file. Not sure it's a packaging issue of JBossAS-5.0.1.GA jdk6 zip file.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 17:45:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 17:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS destinations
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5547098.1243892756643.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6783:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: EmbJopr1_3)


> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS destinations
> -------------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Reporting this on behalf of Emanuel.
> See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 for his original comments.
> In todays meeting he mentioned you get an NPE when setting the messageCounterHistoryDayLimit  property.
> More investigation is needed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 17:49:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 17:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-5286) Add generic
 mbeans/mcbean support into admin console
In-Reply-To: <1935713.1204912257835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16324241.1243892996687.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-5286:
-------------------------------

               Summary: Add generic mbeans/mcbean support into admin console  (was: Getting mbeans/mcbeans into open console)
     Original Estimate: 2 weeks, 2 days  (was: 3 days)
    Remaining Estimate: 2 weeks, 2 days  (was: 3 days)
         Fix Version/s: JBossAS-6.0.0.Alpha1
            Complexity: Medium


Note: this will involve adding support for dynamic resource types to the Jopr platform, which is not a trivial feature to add.


> Add generic mbeans/mcbean support into admin console
> ----------------------------------------------------
>
>                 Key: JBAS-5286
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5286
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Management services, ProfileService
>    Affects Versions: JBossAS-5.0.0.Beta4
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-6.0.0.Alpha1
>
>   Original Estimate: 2 weeks, 2 days
>  Remaining Estimate: 2 weeks, 2 days
>
> How can we get sufficient support for mbeans in the open console to drop the jmx-console.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:00:07 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:00:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-5261) Check each DS and
 Destinations properties are accurate/needed
In-Reply-To: <11075061.1204150422550.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31409795.1243893607822.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer resolved JBAS-5261.
--------------------------------

    Resolution: Done


'allocation-retry' and 'allocation-retry-wait-millis' have been added. 'interleaving' is broken on the JBAS side, so it has not been added for now.


> Check each DS and Destinations properties are accurate/needed
> -------------------------------------------------------------
>
>                 Key: JBAS-5261
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5261
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Mark Spritzler
>            Assignee: Charles Crouch
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ds_5_0.dtd, rhq-plugin.xml
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:00:08 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:00:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-5261) Check each DS and
 Destinations properties are accurate/needed
In-Reply-To: <11075061.1204150422550.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14007819.1243893608085.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer closed JBAS-5261.
------------------------------



> Check each DS and Destinations properties are accurate/needed
> -------------------------------------------------------------
>
>                 Key: JBAS-5261
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5261
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Mark Spritzler
>            Assignee: Charles Crouch
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ds_5_0.dtd, rhq-plugin.xml
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:01:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:01:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6624) EJB3 Session Bean
	metrics
In-Reply-To: <33127819.1237195628532.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6974957.1243893717833.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6624:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> EJB3 Session Bean metrics
> -------------------------
>
>                 Key: JBAS-6624
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6624
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> EJB3 Session Bean metrics (in addition to availability)
>        <!-- ear=rhq.ear,jar=rhq-enterprise-server-ejb.ejb3,name=AgentManagerBean,service=EJB3 -->
>          <!-- jboss.j2ee:jar=SimpleSLSB.jar,name=SimpleSLSB,service=EJB3 -->
>         <metric displayName="Current Count" property="CurrentSize"/>
>          <metric displayName="Create Count" property="CreateCount" displayType="summary" measurementType="trendsup"
>                  description="the number of instances of this EJB that have been created"/>
>          <metric displayName="Remove Count" property="RemoveCount" displayType="summary" measurementType="trendsup"
>                  description="the number of instances of this EJB that have been removed"/>
>          <metric displayName="Available Count" property="AvailableCount"/>
>          <metric displayName="Max Size" property="MaxSize"/>
> Plus the complex method invocation metrics
>  <metric property="InvokeStats" dataType="calltime" units="milliseconds"
>                  defaultOn="false" defaultInterval="600000" destinationType="Method Name"
>                  description="the minimum, maximum, and average invocation times for each of the methods exposed by this EJB;
>                               NOTE: this metric is only available if JBoss EJB3 RC9 Patch 1 or later is being used
>                               (a capable version of EJB3 is included with JBossAS 4.2.0.GA or later)"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:01:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6777) 'interleaving' prop
 on connection
 factories and datasources is always null, even when underlying ds.xml file
 contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18200639.1243893716725.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6777:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:03:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:03:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6625) EJB 1.x or 2.x
	metrics
In-Reply-To: <7034128.1237195628874.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12699808.1243893837080.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6625:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> EJB 1.x or 2.x metrics
> ----------------------
>
>                 Key: JBAS-6625
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6625
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB2, Management services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> EJB 1.x or 2.x Stateless Session Bean metrics (in addition to availability)
>            <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=StatelessSessionBean -->
>            <metric displayName="Create Calls"
>                    property="{stats.createCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Remove Calls"
>                    property="{stats.removeCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Method-Ready Beans"
>                    property="{stats.methodReadyCount.current}"
>                    displayType="summary"/>
>            <metric displayName="Pool Size"
>                    property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}CurrentSize}"/>
>            <metric displayName="Max Pool Size"
>                    property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}MaxSize}"/> 
> Plus the complex method invocation metrics 
>  <metric property="stats" dataType="calltime" units="milliseconds"
>                     defaultOn="false" defaultInterval="600000" destinationType="Method Name"
>                     description="the minimum, maximum, and average invocation times for each of the methods exposed by this EJB"/>
> EJB 1.x or 2.x Stateful Session Bean metrics (in addition to avail):
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=StatefulSessionBean -->
>            <metric displayName="Create Calls"
>                    description="Number of creates executed since the last time this EJB's stats were reset"
>                    property="{stats.createCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Remove Calls"
>                    description="Number of removes since the last time this EJB's stats were reset"
>                    property="{stats.removeCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Method-Ready Beans"
>                    description="The count of beans in the method-ready state"
>                    property="{stats.methodReadyCount.current}"
>                    displayType="summary"/>
>            <metric displayName="Passive Beans"
>                    description="The count of beans in the passivated state"
>                    property="{stats.passiveCount.current}"
>                    displayType="summary"/> 
> EJB 1.x or 2.x Entity Bean metrics (in addition to availability)
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=EntityBean -->
>      <metric displayName="Create Calls"
>               property="{stats.createCount.count}"
>               displayType="summary"
>               measurementType="trendsup"/>
>       <metric displayName="Remove Calls"
>               property="{stats.removeCount.count}"
>               displayType="summary"
>               measurementType="trendsup"/>
>       <metric displayName="Method-Ready Beans"
>               property="{stats.methodReadyCount.current}"
>               displayType="summary"/>
>       <metric displayName="Pooled Beans"
>               property="{stats.pooledCount.current}"
>               displayType="summary"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=cache,service=EJB}CacheSize}"
>                displayName="Cache Size"
>                defaultOn="true"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=cache,service=EJB}PassivatedCount}"
>                displayName="Passivated Count"
>                defaultOn="true"
>                measurementType="trendsup"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}PoolSize}"
>                displayName="Current Size"
>                defaultOn="true"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}MaxPoolSize}"
>                displayName="Max Size"
>                defaultOn="true"/>
> EJB 1.x or 2.x Message Driven Bean metrics (in addition to availability)
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=MessageDrivenBean -->
> <metric displayName="Create Calls"
> property="{stats.createCount.count}"
> displayType="summary"
> measurementType="trendsup"/>
> <metric displayName="Remove Calls"
> property="{stats.removeCount.count}"
> displayType="summary"
> measurementType="trendsup"/>
> <metric displayName="Method-Ready Beans"
> property="{stats.messageCount.count}"
> displayType="summary"
>               measurementType="trendsup"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:03:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:03:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30539137.1243893837390.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6808:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:03:59 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:03:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6784) Add support for JMS
 ServerPeer
 managed object to support enabling metric collection through the console
In-Reply-To: <4119905.1239740302404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16703829.1243893839080.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6784:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> Add support for JMS ServerPeer managed object to support enabling metric collection through the console
> -------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6784
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6784
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Charles Crouch
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> See 
> https://jira.jboss.org/jira/browse/JBAS-6720?focusedCommentId=12461916#action_12461916
> https://jira.jboss.org/jira/browse/JBAS-6720?focusedCommentId=12461917#action_12461917
> for more info on why this would be a good thing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:05:58 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 1 Jun 2009 18:05:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1637) Interruption
	is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13823805.1243893958159.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

David Lloyd updated JBMESSAGING-1637:
-------------------------------------

    Attachment: fix-interruption.patch


> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Tim Fox
>            Priority: Blocker
>             Fix For: 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:05:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:05:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6877) EJB3 Cache Metrics
In-Reply-To: <13995931.1241642506748.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3573919.1243893957988.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6877:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> EJB3 Cache Metrics
> ------------------
>
>                 Key: JBAS-6877
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6877
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>            Reporter: Andrew Lee Rubinger
>            Assignee: Brian Stansberry
>             Fix For: Backlog
>
>
> These statistics must be reflected in the admin-console/Jopr.
> Split from JBAS-6624:
> EJB3 Entity Tree Cache (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache-->
> <metric property="NumberOfLocksHeld" displayType="summary"/>
>          <metric property="NumberOfNodes" displayType="summary"/>
> EJB3 Entity Tree Cache Interceptor (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache,treecache-interceptor=CacheMgmtInterceptor-->
>             <metric property="HitMissRatio" displayType="summary" units="percentage"
>                     description="Returns the hit/miss ratio for the cache. This ratio is defined as hits/(hits + misses)."/>
>             <metric property="ReadWriteRatio" displayType="summary" units="percentage"
>                     description="Returns the read/write ratio for the cache. This ratio is defined as (hits + misses)/stores."/>
>             <metric property="Hits" displayType="summary"/>
>             <metric property="Misses" displayType="summary"/>
>             <metric property="Evictions" displayType="summary"/>
>             <metric property="NumberOfLocksHeld"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="AverageWriteTime" units="milliseconds"/>
>             <metric property="TimeSinceReset" units="seconds"/>
>             <metric property="AverageReadTime" units="milliseconds"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="Stores"/>
>             <metric property="NumberOfAttributes"/>
>             <metric property="ElapsedTime" units="milliseconds"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:05:57 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 1 Jun 2009 18:05:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1637) Interruption
	is busted
Message-ID: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>

Interruption is busted
----------------------

                 Key: JBMESSAGING-1637
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.3.GA, 1.4.1.GA
            Reporter: David Lloyd
            Assignee: Tim Fox
            Priority: Blocker
             Fix For: 1.4.5.GA
         Attachments: fix-interruption.patch

Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:09:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6693) Add deployExploded
 argument to DeploymentManager.distribute()
In-Reply-To: <22761801.1238177902939.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20578810.1243894196595.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6693:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> Add deployExploded argument to DeploymentManager.distribute()
> -------------------------------------------------------------
>
>                 Key: JBAS-6693
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6693
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Charles Crouch
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> It would be helpful if we could tell the DeploymentManager to expand the archive when its deployed, since linked issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:09:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:09:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6979)
 org.jboss.dependency.spi.ControllerState class (from jboss-dependency.jar)
 required by remote Profile Service client calling
 ManagementView.getDeployment()
In-Reply-To: <28592167.1243393316467.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3158039.1243894197106.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6979:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> org.jboss.dependency.spi.ControllerState class (from jboss-dependency.jar) required by remote Profile Service client calling ManagementView.getDeployment()
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6979
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6979
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>
> I'm assuming this class should not be required by a remote client.
> Here's the stack trace:
> 2009-05-26 22:41:31,357 WARN  [InventoryManager.discovery-1] (rhq.core.pc.inventory.InventoryManager)- Failure during discovery for [EJB3 JAR] Resources - failed after 156 ms.
> java.lang.Exception: Discovery component invocation failed.
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:248)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NoClassDefFoundError: org/jboss/dependency/spi/ControllerState
> 	at org.jboss.profileservice.spi.types.ControllerStateMetaType.<init>(ControllerStateMetaType.java:53)
> 	at org.jboss.profileservice.spi.types.ControllerStateMetaType.<clinit>(ControllerStateMetaType.java:49)
> 	at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> 	at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> 	at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> 	at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
> 	at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
> 	at java.lang.reflect.Field.getLong(Field.java:528)
> 	at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1614)
> 	at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
> 	at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:413)
> 	at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.managed.plugins.DefaultFieldsImpl.readObject(DefaultFieldsImpl.java:378)
> 	at sun.reflect.GeneratedMethodAccessor380.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.managed.plugins.ManagedPropertyImpl.readVersion1(ManagedPropertyImpl.java:652)
> 	at org.jboss.managed.plugins.ManagedPropertyImpl.readObject(ManagedPropertyImpl.java:626)
> 	at sun.reflect.GeneratedMethodAccessor379.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at AOPProxy$1.getDeployment(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.AbstractManagedDeploymentDiscoveryComponent.discoverResources(AbstractManagedDeploymentDiscoveryComponent.java:86)
> 	at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
> 	... 5 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.dependency.spi.ControllerState
> 	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 org.rhq.core.pc.plugin.ChildFirstPluginClassLoader.loadClass(ChildFirstPluginClassLoader.java:68)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> 	... 87 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:09:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 1 Jun 2009 18:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1637) Interruption
	is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18275530.1243894196766.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic updated JBMESSAGING-1637:
-----------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


Howard, can you take a look please?

> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:11:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:11:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6984) trying to remotely
 retrieve
 statistic properties (e.g. rollbackCount) from MCBean:JTA managed
 components results in "ClassNotFoundException:
 com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
In-Reply-To: <11628190.1243511107980.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26434668.1243894317257.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6984:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> trying to remotely retrieve statistic properties (e.g. rollbackCount) from MCBean:JTA managed components results in "ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6984
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6984
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>
> 2009-05-28 07:40:01,544 ERROR [ResourceContainer.invoker.daemon-364] (org.rhq.plugins.jbossas5.ApplicationServerComponent)- Failed to obtain metric 'MCBean|JTA|*|rollbackCount'.
> java.lang.IllegalStateException: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:160)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
> 	at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
> 	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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> 	at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1462)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1312)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	... 11 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:11:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6980)
 "ClassNotFoundException:
 org.jboss.aop.instrument.Untransformable" occurs when
 ManagementView.getComponentsForType(<MBean:WebApplication>) is called from
 a remote client
In-Reply-To: <15938916.1243426198456.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17370238.1243894316748.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6980:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> "ClassNotFoundException: org.jboss.aop.instrument.Untransformable" occurs when ManagementView.getComponentsForType(<MBean:WebApplication>) is called from a remote client
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6980
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6980
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>
> Note, this occurs even though I have jboss-aop-client.jar, which contains org.jboss.aop.instrument.Untransformable, in my client's classpath. Here's the stack trace:
> 2009-05-27 07:54:31,035 WARN  [InventoryManager.discovery-1] (rhq.core.pc.inventory.InventoryManager)- Failure during discovery for [Embedded Web Application Context] Resources - failed after 250 ms.
> java.lang.Exception: Discovery component invocation failed.
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:248)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.IllegalStateException: org.jboss.remoting.InvocationFailureException: Unable to perform invocation; nested exception is: 
> 	java.lang.RuntimeException: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:160)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:141)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.getWebApplicationComponents(WebApplicationContextDiscoveryComponent.java:182)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.discoverResources(WebApplicationContextDiscoveryComponent.java:90)
> 	at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
> 	... 5 more
> Caused by: org.jboss.remoting.InvocationFailureException: Unable to perform invocation; nested exception is: 
> 	java.lang.RuntimeException: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:142)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:891)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	... 12 more
> Caused by: java.lang.RuntimeException: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at org.jboss.aop.proxy.MarshalledInterfaceProxy.readResolve(MarshalledInterfaceProxy.java:76)
> 	at sun.reflect.GeneratedMethodAccessor973.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:141)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.getWebApplicationComponents(WebApplicationContextDiscoveryComponent.java:182)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.discoverResources(WebApplicationContextDiscoveryComponent.java:90)
> 	at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	... 19 more
> Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at javassist.ClassPool.toClass(ClassPool.java:1035)
> 	at javassist.scopedpool.ScopedClassPool.toClass(ScopedClassPool.java:306)
> 	at javassist.CtClass.toClass(CtClass.java:1094)
> 	at org.jboss.aop.instrument.TransformerCommon$ToClassAction$2.toClass(TransformerCommon.java:331)
> 	at org.jboss.aop.instrument.TransformerCommon.toClass(TransformerCommon.java:139)
> 	at org.jboss.aop.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:126)
> 	at org.jboss.aop.proxy.ProxyFactory.createInterfaceProxy(ProxyFactory.java:96)
> 	at org.jboss.aop.proxy.MarshalledInterfaceProxy.readResolve(MarshalledInterfaceProxy.java:72)
> 	at sun.reflect.GeneratedMethodAccessor973.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	... 19 more
> Caused by: java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
> 	at sun.reflect.GeneratedMethodAccessor974.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at javassist.ClassPool.toClass2(ClassPool.java:1047)
> 	at javassist.ClassPool.toClass(ClassPool.java:1029)
> 	... 82 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.aop.instrument.Untransformable
> 	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)
> 	... 89 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:11:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:11:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6982) unable to connect to
 Profile Service remotely using EJB remote interface
In-Reply-To: <33034814.1243442816774.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17317938.1243894317047.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6982:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> unable to connect to Profile Service remotely using EJB remote interface
> ------------------------------------------------------------------------
>
>                 Key: JBAS-6982
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6982
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>
> The non-EJB remote interface is working, with the exception of the various class loading exceptions. The EJB interface is not, due to an authentication failure, but I think it used to work.
> Here's the log output showing me doing the JNDI lookup of the EJB proxies:
> DEBUG 27-05 12:40:03,988 (RemoteProfileServiceConnectionProvider.java:doConnect:90)  -Connecting to Profile Service via remote JNDI using env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:03,988 (AbstractProfileServiceConnectionProvider.java:createInitialContext:74)  -Creating JNDI InitialContext with env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:04,004 (Logger.java:debug:228)  -Using ThreadLocal: false
> DEBUG 27-05 12:40:04,035 (AbstractProfileServiceConnectionProvider.java:createInitialContext:83)  -Created JNDI InitialContext [javax.naming.InitialContext at 1ccb029].
> DEBUG 27-05 12:40:04,035 (Logger.java:debug:228)  -createSocket, hostAddr: /127.0.0.1, port: 1099, localAddr: null, localPort: 0, timeout: 0
> DEBUG 27-05 12:40:04,191 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureProfileService/remote
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Encrypted Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -removed SocketClientInvoker[3820e, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -Created Proxy of type $Proxy1 for EJB3 Business Interface: org.jboss.profileservice.spi.ProfileService
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureManagementView/remote
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -removed SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Created Proxy of type $Proxy3 for EJB3 Business Interface: org.jboss.deployers.spi.management.ManagementView
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureDeploymentManager/remote
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -removed SocketClientInvoker[12940b3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Created Proxy of type $Proxy5 for EJB3 Business Interface: org.jboss.deployers.spi.management.deploy.DeploymentManager
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Couldn't handle invocation directly within org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8: Current invocation "public abstract boolean org.jboss.deployers.spi.management.ManagementView.load()" is not eligible for direct handling by org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Received invocation request to method org.jboss.deployers.spi.management.ManagementView: org.jboss.deployers.spi.management.ManagementView.load(); using hash: -657996635075089079
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -removed SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] disconnecting ...
> And here's the "EJBAccessException: Caller unauthorized" that occurs when I call load() on the ManagementView proxy:
> Exception in thread "main" javax.ejb.EJBAccessException: Caller unauthorized
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:199)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         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:524)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 22:58:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Mon, 1 Jun 2009 22:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-84) Set a default MO.name
 to the MO.componentName
Message-ID: <9292835.1243911536683.JavaMail.jira@cloud.prod.atl2.jboss.com>

Set a default MO.name to the MO.componentName
---------------------------------------------

                 Key: JBMAN-84
                 URL: https://jira.jboss.org/jira/browse/JBMAN-84
             Project: JBoss Managed
          Issue Type: Feature Request
          Components: managedobject
            Reporter: Scott M Stark
            Assignee: Scott M Stark
             Fix For:  JBossMan.2.1.1.Beta1


If a ManagedObject has a defaulted name, the name should be set to the ManagedObject.componentName if one exists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 23:10:06 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Mon, 1 Jun 2009 23:10:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-84) Set a default
 MO.name to the MO.componentName
In-Reply-To: <9292835.1243911536683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19615348.1243912206809.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBMAN-84.
--------------------------------

    Resolution: Done


> Set a default MO.name to the MO.componentName
> ---------------------------------------------
>
>                 Key: JBMAN-84
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-84
>             Project: JBoss Managed
>          Issue Type: Feature Request
>          Components: managedobject
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For:  JBossMan.2.1.1.Beta1
>
>
> If a ManagedObject has a defaulted name, the name should be set to the ManagedObject.componentName if one exists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 23:21:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 1 Jun 2009 23:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-75) Allow for shutdown
 to interrupt startup
In-Reply-To: <28571693.1242320326783.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17743846.1243912916458.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger resolved JBBOOT-75.
---------------------------------------

    Fix Version/s: 2.0.0-alpha-1
                       (was: Unscheduled)
       Resolution: Done


> Allow for shutdown to interrupt startup
> ---------------------------------------
>
>                 Key: JBBOOT-75
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-75
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-base
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-alpha-1
>
>
> Both startup and shutdown block on the same "this" reference, meaning that the server may not be shutdown until startup is complete.  As DML advises, use an interrupt mechanism to allow another Thread to interrupt startup.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 23:21:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 1 Jun 2009 23:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6974) Ensure the Shutdown
 Hook fully shuts down the Server
In-Reply-To: <20457385.1243304636427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20824571.1243912916595.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger updated JBAS-6974:
--------------------------------------

    Attachment:     (was: JBAS-6974.patch)


> Ensure the Shutdown Hook fully shuts down the Server
> ----------------------------------------------------
>
>                 Key: JBAS-6974
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6974
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Shutdown Hook is not calling full shutdown before the process exits.
> For starters, there's this:
> if (currentState.equals(LifecycleState.STARTED) || currentState.equals(LifecycleState.STARTING))
> Find other possible problems and ensure the lifecycle goes through full shutdown before the VM can terminate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 23:28:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 1 Jun 2009 23:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6974) Ensure the Shutdown
 Hook fully shuts down the Server
In-Reply-To: <20457385.1243304636427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5564546.1243913336785.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger updated JBAS-6974:
--------------------------------------

    Attachment: JBAS-6974.patch


> Ensure the Shutdown Hook fully shuts down the Server
> ----------------------------------------------------
>
>                 Key: JBAS-6974
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6974
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: JBAS-6974.patch
>
>
> Shutdown Hook is not calling full shutdown before the process exits.
> For starters, there's this:
> if (currentState.equals(LifecycleState.STARTED) || currentState.equals(LifecycleState.STARTING))
> Find other possible problems and ensure the lifecycle goes through full shutdown before the VM can terminate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 02:18:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 2 Jun 2009 02:18:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6624) EJB3 Session Bean
	metrics
In-Reply-To: <33127819.1237195628532.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10850307.1243923537225.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger commented on JBAS-6624:
-------------------------------------------

I've added the jboss-ejb3-metrics-deployer into the AS Build in JBPAPP_5_0 in r89649.

At this point only minor changes to the mappings should be left; I'll wait to hear requests from the JON team.

> EJB3 Session Bean metrics
> -------------------------
>
>                 Key: JBAS-6624
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6624
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> EJB3 Session Bean metrics (in addition to availability)
>        <!-- ear=rhq.ear,jar=rhq-enterprise-server-ejb.ejb3,name=AgentManagerBean,service=EJB3 -->
>          <!-- jboss.j2ee:jar=SimpleSLSB.jar,name=SimpleSLSB,service=EJB3 -->
>         <metric displayName="Current Count" property="CurrentSize"/>
>          <metric displayName="Create Count" property="CreateCount" displayType="summary" measurementType="trendsup"
>                  description="the number of instances of this EJB that have been created"/>
>          <metric displayName="Remove Count" property="RemoveCount" displayType="summary" measurementType="trendsup"
>                  description="the number of instances of this EJB that have been removed"/>
>          <metric displayName="Available Count" property="AvailableCount"/>
>          <metric displayName="Max Size" property="MaxSize"/>
> Plus the complex method invocation metrics
>  <metric property="InvokeStats" dataType="calltime" units="milliseconds"
>                  defaultOn="false" defaultInterval="600000" destinationType="Method Name"
>                  description="the minimum, maximum, and average invocation times for each of the methods exposed by this EJB;
>                               NOTE: this metric is only available if JBoss EJB3 RC9 Patch 1 or later is being used
>                               (a capable version of EJB3 is included with JBossAS 4.2.0.GA or later)"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 02:22:56 2009
From: jira-events at lists.jboss.org (Greg Barton (JIRA))
Date: Tue, 2 Jun 2009 02:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2101) Intermittant
 NullPointerException when invoking StatefulSession.asyncUpdate() while
 maintainTms==true
Message-ID: <27736937.1243923776508.JavaMail.jira@cloud.prod.atl2.jboss.com>

Intermittant NullPointerException when invoking StatefulSession.asyncUpdate() while maintainTms==true
-----------------------------------------------------------------------------------------------------

                 Key: JBRULES-2101
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2101
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
         Environment: Ubuntu Jaunty Jackelope
Linux version 2.6.27-11-generic (buildd at yellow) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) ) #1 SMP Wed Apr 1 20:53:41 UTC 2009
Multicore 
            Reporter: Greg Barton
            Assignee: Mark Proctor


After calling StatefulSession.asyncUpdate() the following exception occurs, but only when maintainTms==true in the rule configuration:

Exception in thread "Thread-5" java.lang.NullPointerException                                                                                       
        at org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1387)                                                          
        at org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1350)                                                          
        at org.drools.concurrent.UpdateObject.execute(UpdateObject.java:46)                                                                         
        at org.drools.concurrent.CommandExecutor.run(CommandExecutor.java:78)                                                                       
        at java.lang.Thread.run(Thread.java:619) 

AbstractWorkingMemory.java line 1387 is wrapped in an if statement with condition "this.maintainTms" so setting maintainTms=false avoids the exception entirely.  The NPE producing line is this:

status = ((InternalFactHandle) factHandle).getEqualityKey().getStatus();

While encountering this problem the factHandle passed in to StatefulSession.asyncUpdate() was always non-null, so my guess is that the getEqualityKey() call returned null.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 02:53:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 2 Jun 2009 02:53:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1637)
	Interruption is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28774218.1243925637180.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1637:
-----------------------------------------

Hi David,

In your patch:

     boolean intr = Thread.interrupted();
     for (;;) try
     {
        lock.readLock().acquire();
        break;
     }
    catch (InterruptedException ex)
     {
        intr = true;
     }

I don't understand why in JBM needs to reset the interrupted state of the calling thread. My reason:

1. If the thread is interrupted by someone, JBM assumes no responsibility of resetting it. The interrupter should know of the consequence of his action and be prepared for any exceptions caused by this interruption. Actually this code may produce an effect that against the will of the interrupter, see the following comment from JBAS-6546:

...To avoid a rogue plugin degrading the plugin container performance as a whole, the plugin container invokes plugin component methods via a thread pool/future/timeout mechanism - if a plugin component's facet method takes too long to complete, a timeout will trigger, the plugin container will abort and the thread will be interrupted.

So if the above code is applied, it possible that the thread will wait there for long even if the caller has interrupted it. 


2. The acquire() method's InterruptedException indicates a failure of acquiring the lock, nothing more nothing less. We can't assume too much about the internal impl of this method. If in an environment we're having problem in getting synchronization, then it is a good reason JBM throws exception notifying any interested party that JBM is not able to work properly under such a condition. 

wdyt?

Howard


> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 05:16:04 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 2 Jun 2009 05:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1637) Interruption
	is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25747193.1243934164593.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1637:
---------------------------------

    Priority: Major  (was: Blocker)


> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>             Fix For: 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 05:24:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 2 Jun 2009 05:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1637)
	Interruption is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28462668.1243934696791.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox commented on JBMESSAGING-1637:
--------------------------------------

Where does this originally come from?

I'm guessing it's because the new AS console has a (new) requirement that all component operations need to be interruptible? If so, we can deal with that, but I wouldn't expect all operations, especially in the older 1.x code base to allow ops to be interrupted.

We've never made the claim that our operations are interruptible.

> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>             Fix For: 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 05:55:08 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Tue, 2 Jun 2009 05:55:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Admin Join problem
 -GMS flush by coordinator failed
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8822685.1243936508210.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Vladimir Blagojevic commented on JGRP-985:
------------------------------------------

I am trying to reproduce this issue on my local machine using JGroups2.8.0Alpha3 and I am unable to do so. I have augmented your test locally not to execute getState and I have used default flush-udp.xml instead of your jgroups.xml since yours does not include UNICAST protocol. To be honest, I do see a couple of timeouts and attempted rejoins but they all eventually succeed. I used three terminals and I cycled through them just as you described for about 10 minutes.



> Admin  Join problem -GMS flush by coordinator failed
> ----------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 06:23:56 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 2 Jun 2009 06:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-442) Aggregate
 the respective API docs
In-Reply-To: <1566030.1242724505227.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20937335.1243938236429.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMICROCONT-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470194#action_12470194 ] 

Thomas Diesler commented on JBMICROCONT-442:
--------------------------------------------

Jason sais

All of our code, especially SPI or API classes must have javadoc which explains in detail the following things:

1) How the module is supposed to be used (and how it is actually used if known)
2) The intended behaviour, and any aspect of it that is known to be broken or a hack (so that someone can differentiate between a design problem and just an unimplemented section that needs to be fixed)
3) Critical preconditions (e.g. "this class expects that the same vfs handle instance be reused during a redeploy")
4) Thread-access design (e.g. "this class is thread-safe and can be accessed from multiple threads", "this class is not thread-safe, and all callers must use a shared lock to access", "this class is intended to have an instance-per-thread")


> Aggregate the respective API docs
> ---------------------------------
>
>                 Key: JBMICROCONT-442
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-442
>             Project: JBoss Microcontainer
>          Issue Type: Task
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: JBossMC-2.0.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 06:32:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 2 Jun 2009 06:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1840) StrictMaxPool
 does not
 maintain a correct "inUse" count leading to incorrect reporting of
 "AvailableCount"
In-Reply-To: <742346.1243851896474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28656239.1243938776599.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai resolved EJBTHREE-1840.
------------------------------------

                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-core:1.1.7


StrictMaxPool has been fixed to avoid decrementing the inUse counter multiple times for the same context

> StrictMaxPool does not maintain a correct "inUse" count leading to incorrect reporting of "AvailableCount"
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1840
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1840
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.6
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> The org.jboss.ejb3.test.stateless.unit.MetricsUnitTestCase shows a failure w.r.t the "AvailableCount" of a bean marked with StrictMaxPool. 
> The StrictMaxPool internally implements the getAvailableCount() as follows:
>    public int getAvailableCount()
>    {
>       return maxSize - inUse;
>    }
> The "inUse" count is handled incorrectly in the discard and remove method of this pool leading to that count reaching a negative value. Ultimately, this leads to incorrect available count being reported.
> When an exception occurs, the bean is discarded from the pool. This leads to a call on discard method of the StrictMaxPool which decrements the inUse count and then calls the remove method which *again* decrements the inUse count for the same bean context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 06:32:56 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 2 Jun 2009 06:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6994) Improve developer
	javadoc
Message-ID: <32936935.1243938776460.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve developer javadoc
-------------------------

                 Key: JBAS-6994
                 URL: https://jira.jboss.org/jira/browse/JBAS-6994
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Other
            Reporter: Thomas Diesler
             Fix For: JBossAS-6.0.0.Alpha1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 06:32:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 2 Jun 2009 06:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1840) StrictMaxPool
 does not
 maintain a correct "inUse" count leading to incorrect reporting of
 "AvailableCount"
In-Reply-To: <742346.1243851896474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16196879.1243938776712.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470197#action_12470197 ] 

jaikiran pai commented on EJBTHREE-1840:
----------------------------------------

org/jboss/ejb3/test/stateless/unit/MetricsUnitTestCase in ejb3-testsuite has the necessary tests.


> StrictMaxPool does not maintain a correct "inUse" count leading to incorrect reporting of "AvailableCount"
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1840
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1840
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.6
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> The org.jboss.ejb3.test.stateless.unit.MetricsUnitTestCase shows a failure w.r.t the "AvailableCount" of a bean marked with StrictMaxPool. 
> The StrictMaxPool internally implements the getAvailableCount() as follows:
>    public int getAvailableCount()
>    {
>       return maxSize - inUse;
>    }
> The "inUse" count is handled incorrectly in the discard and remove method of this pool leading to that count reaching a negative value. Ultimately, this leads to incorrect available count being reported.
> When an exception occurs, the bean is discarded from the pool. This leads to a call on discard method of the StrictMaxPool which decrements the inUse count and then calls the remove method which *again* decrements the inUse count for the same bean context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 06:34:56 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 2 Jun 2009 06:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6994) Improve developer
	javadoc
In-Reply-To: <32936935.1243938776460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1597390.1243938896365.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Thomas Diesler updated JBAS-6994:
---------------------------------

    Description: 
Jason sais

The javadoc/code comments in our core modules are VERY lacking, so it is incredibly difficult for new folks to understand how anything is supposed to work (I have been hearing some groaning about this recently).

All of our code, especially SPI or API classes must have javadoc which explains in detail the following things:

1) How the module is supposed to be used (and how it is actually used if known)
2) The intended behavior, and any aspect of it that is known to be broken or a hack (so that someone can differentiate between a design problem and just an unimplemented section that needs to be fixed)
3) Crticial preconditions (e.g. "this class expects that the same vfs handle instance be reused during a redeploy")
4) Thread-access design (e.g. "this class is thread-safe and can be accessed from multiple threads", "this class is not thread-safe, and all callers must use a shared lock to access", "this class is intended to have an instance-per-thread")

If we can't answer these simple questions, then it is likely our design is flawed.



> Improve developer javadoc
> -------------------------
>
>                 Key: JBAS-6994
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6994
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Thomas Diesler
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Jason sais
> The javadoc/code comments in our core modules are VERY lacking, so it is incredibly difficult for new folks to understand how anything is supposed to work (I have been hearing some groaning about this recently).
> All of our code, especially SPI or API classes must have javadoc which explains in detail the following things:
> 1) How the module is supposed to be used (and how it is actually used if known)
> 2) The intended behavior, and any aspect of it that is known to be broken or a hack (so that someone can differentiate between a design problem and just an unimplemented section that needs to be fixed)
> 3) Crticial preconditions (e.g. "this class expects that the same vfs handle instance be reused during a redeploy")
> 4) Thread-access design (e.g. "this class is thread-safe and can be accessed from multiple threads", "this class is not thread-safe, and all callers must use a shared lock to access", "this class is intended to have an instance-per-thread")
> If we can't answer these simple questions, then it is likely our design is flawed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 07:20:57 2009
From: jira-events at lists.jboss.org (John Hornsby (JIRA))
Date: Tue, 2 Jun 2009 07:20:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6995) portlet fails to
 start in liferay 5.2.3 Jboss 5.0.0 bundle but no errors
Message-ID: <18535326.1243941657598.JavaMail.jira@cloud.prod.atl2.jboss.com>

portlet fails to start in liferay 5.2.3 Jboss 5.0.0 bundle but no errors
------------------------------------------------------------------------

                 Key: JBAS-6995
                 URL: https://jira.jboss.org/jira/browse/JBAS-6995
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.0.0.GA
         Environment: Win Vista (also tried Win XP, and Ubuntu Linux), Java jdk1.5.0_07 (also tried java jdk1.6.0_02), Using HSQLDB.   Same problem using the liferay-portal-jboss-tomcat-5.0-5.2.3.zip and the liferay-portal-jboss-tomcat-5.0-5.2.2.zip bundles.
The portlet works successfully in liferay_tomcat bundles.
            Reporter: John Hornsby


Problems deploying portlet successfully.   The auto-deployment appears to work OK (there are no errors in any log) but it doesn't start up and doesn't appear in the Add Applications dialogue in Liferay:

10:00:05,753 INFO  [STDOUT]   Expanding: C:\LR523\deploy\konakartadmin.war into C:\Users\John\AppData\Local\Temp\20090602100005480
10:00:11,931 INFO  [STDOUT]   Copying 1 file to C:\Users\John\AppData\Local\Temp\20090602100005480\WEB-INF\classes
10:00:13,219 INFO  [STDOUT]   Warning: META-INF\MANIFEST.MF modified in the future.
10:00:13,560 INFO  [STDOUT]   Copying 149 files to C:\LR523\jbt\server\default\deploy\konakartadmin.war
10:00:17,393 INFO  [STDOUT]   Copying 1 file to C:\LR523\jbt\server\default\deploy\konakartadmin.war
10:00:18,027 INFO  [STDOUT]   Deleting directory C:\Users\John\AppData\Local\Temp\20090602100005480
10:00:23,125 INFO  [STDOUT] 10:00:23,124 INFO  [PortletAutoDeployListener] Portlets for C:\LR523\deploy\konakartadmin.war copied successfully. Deployment will start in a few seconds.
10:01:00,269 INFO  [TomcatDeployment] deploy, ctxPath=/konakartadmin, vfsUrl=konakartadmin.war

After the "Deployment will start in a few seconds." I would expect to see the service actually start but it doesn't.  No clues as to why appear in the server .log, which actually reports that the war is fully deployed:

2009-06-02 10:55:53,745 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner) Initialized: {WebApplication: /C:/LR523/jbt/server/default/deploy/konakartadmin.war/, URL: vfsfile:/C:/LR523/jbt/server/default/deploy/konakartadmin.war/, classLoader: BaseClassLoader at 13c92ad{vfsfile:/C:/LR523/jbt/server/default/deploy/konakartadmin.war/}:20746925} jboss.web:j2eeType=WebModule,name=//localhost/konakartadmin,J2EEApplication=none,J2EEServer=none
2009-06-02 10:55:53,750 DEBUG [org.jboss.deployers.plugins.deployers.DeployersImpl] (HDScanner) Fully Deployed vfsfile:/C:/LR523/jbt/server/default/deploy/konakartadmin.war/

When I shut JBoss down it tells me that the services (defined in my war) were not started:

10:49:13,352 INFO  [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[FileUpload] has not been started
10:49:13,373 INFO  [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[jsp] has not been started
10:49:13,393 INFO  [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[default] has not been started
10:49:13,412 INFO  [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[kk_admin_portlet] has not been started
10:49:13,433 INFO  [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[KonaKartAdminServlet] has not been started


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 09:22:57 2009
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Tue, 2 Jun 2009 09:22:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6983) Error configuring
 property: sessionIdAlphabet for WarDeployer
In-Reply-To: <16967894.1243494296657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4399899.1243948977113.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Remy Maucherat reassigned JBAS-6983:
------------------------------------

    Assignee: Brian Stansberry  (was: Remy Maucherat)


Yes, looking at the code, there is a problem with this flag.

This is apparently mapped to a server wide property, and it is set using a service specific property. It could be set using a system property instead. Either way, it needs some modifications. An additional consideration is that Tomcat never had a session id alphabet flag. Probably the broken mobile browsers got fixed. Is there still a real need for that ?

Assign to Brian to look at the options.

> Error configuring property: sessionIdAlphabet for WarDeployer
> -------------------------------------------------------------
>
>                 Key: JBAS-6983
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6983
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: JBoss 5.0.1.GA or JBoss 5.1.0.GA
>            Reporter: Manuel Aznar Perez
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> At "server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml" when i uncomment "<property name="sessionIdAlphabet">" and run JBoss. Launch exception:
> 2009-05-28 08:34:34,670 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Configured: name=WarDeployer state=Instantiated
> java.lang.RuntimeException: Error configuring property: sessionIdAlphabet for WarDeployer
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112)
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85)
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44)
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
>         at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
>         at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
>         at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> That is because don't have "jboss-web-service.jar" in deployer. 
> This jar is in "deploy/jbossweb.sar".
> This is fixed copy jar file to deployer directory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 09:43:03 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 2 Jun 2009 09:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-201) Provide a
 validator to check
 for the presence of atleast one business interface on a EJB3 bean
In-Reply-To: <12119065.1242889616485.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30631023.1243950183269.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai resolved JBMETA-201.
---------------------------------

    Resolution: Done


Done in r89668

> Provide a validator to check for the presence of atleast one business interface on a EJB3 bean
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-201
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-201
>             Project: JBoss Metadata
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> Provide a validator which validates that the EJB3 bean exposes atleast one business interface.
> Please see the referenced forum thread for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 09:43:03 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 2 Jun 2009 09:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-201) Provide a validator
 to check for
 the presence of atleast one business interface on a EJB3 bean
In-Reply-To: <12119065.1242889616485.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26553484.1243950183464.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai updated JBMETA-201:
--------------------------------

    Fix Version/s: 1.0.2.Beta1


> Provide a validator to check for the presence of atleast one business interface on a EJB3 bean
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-201
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-201
>             Project: JBoss Metadata
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.0.2.Beta1
>
>
> Provide a validator which validates that the EJB3 bean exposes atleast one business interface.
> Please see the referenced forum thread for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 10:06:57 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 2 Jun 2009 10:06:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1637)
	Interruption is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4765460.1243951617497.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

David Lloyd commented on JBMESSAGING-1637:
------------------------------------------

Tim, being able to handle interruption is not optional, something that you support or don't support.  When you run in a container it's just a matter of time before something trips the interrupt status - your caller might use it, or a callee might use it.  Not supporting interruption is a bug.  My patch simply adopts a policy of deferring the interrupt in a safe manner, which fixes the bug.  Now if you want interruption to prematurely cancel an event in a clean way, that is a feature that you are free to implement if you wish.

Howard, in response to 1., *everyone* that invokes an interruptible operation has the responsibility of resetting the interrupted status.  If there is no sane way to handle interruption (because, for example, someone thought it might be a good idea to throw Exception from a method), then the only other option is to ignore it but *preserve* the flag setting, so the caller has a chance to handle it.  Yes, this means that things may keep running after interruption.  But this is what your options are unless you're willing to go through and strip out all those "throws Exceptions", replace them with "throws InterruptedException, XxxxException, ..." *and* locate all the call sites and remove *their* "catch (Exception e)" and replace them with interrupt-aware handlers, and *then* go through and apply sane interrupt handling to all those call sites.

The goal here isn't to make JBM interruptible - that would be a lot more work - but to fix the bug that it has no strategy whatsoever to handle interruption, resulting in all kinds of possible problems.  If JBM was using j.u.c instead of oswego, I would have simply replaced the lock calls with uninterruptible lock calls.

As for (2), you are incorrect.  InterruptedException indicates that the thread was interrupted while acquiring the lock.  As I've said many times before, when you invoke an operation that can throw InterruptedException, your choices are to preserve the interrupt status and retry the operation, preserve interrupt status and throw some other exception, or rethrow InterruptedException itself *after* correctly handing the interrupt situation by aborting what you're doing in a clean manner (whether that be rolling back your operation or whatever).  Since JBM 1.x was obviously not designed with interruption in mind, the first option is the safest.  You may disagree and decide to go ahead and refactor all these methods and their call sites.  But remember this.  Any operation which throws InterruptedException should be *retryable* (in other words, you must give the caller the opportunity to decide whether they care that an operation was interrupted - maybe they don't and they want to retry it anyway).  If you make your operation interruptible and it is not retryable, you should not be throwing InterruptedException, but instead, re-set the interrupt status of the current thread and throw some other exception.

> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>             Fix For: 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Tue Jun  2 10:08:58 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 2 Jun 2009 10:08:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <29694520.1243951738548.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1631:
-----------------------------------------

Hi Victor,

I wrote up a test case that looks like that:

1) Start up a two-node jbm cluster, messaging-node0 and messaging-node1. A distributed queue also deployed.
2) Deploy a MDB jar to messaging-node0/farm. The MDB receives messages from the distributed queue.
3) Start a message sending application and send the messages over ClusteredConnectionFactory. The messages will be sent to the two node in round-robin fashion.

I got it run on one machine. However, to be able to reproduce the issue, I think I need to deploy the cluster to two machines.

If you got a chance, can you comment on whether my test is suitable or not? Thanks. I'll update you once I got it run over certain time.

Howard



> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: logs-and-config-prod.zip, logs-and-config-test.zip
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 11:11:56 2009
From: jira-events at lists.jboss.org (Ben Abernathy (JIRA))
Date: Tue, 2 Jun 2009 11:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1841) Improve logging
 for InterceptorsFactory warning
Message-ID: <17265944.1243955516468.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve logging for InterceptorsFactory warning
-----------------------------------------------

                 Key: EJBTHREE-1841
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1841
             Project: EJB 3.0
          Issue Type: Task
    Affects Versions: AS 5.0.0.CR1
         Environment: Windows XP 32-bit, JBoss AS 5.1.0GA
            Reporter: Ben Abernathy


Every time this section of code is called, the following warning is displayed:

09:02:34,655 WARN  [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container

Upon inspecting EJBTHREE-1246, it appears this warning can be ignored by bean developers. If that is the case, is it necessary to fill up the console and log with benign warnings? There can be lots of these if the application is large.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 11:44:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 2 Jun 2009 11:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-85) Don't override the
 @ManagementObjectID with a default name.
Message-ID: <21603131.1243957496670.JavaMail.jira@cloud.prod.atl2.jboss.com>

Don't override the @ManagementObjectID with a default name.
-----------------------------------------------------------

                 Key: JBMAN-85
                 URL: https://jira.jboss.org/jira/browse/JBMAN-85
             Project: JBoss Managed
          Issue Type: Bug
    Affects Versions:  JBossMan.2.1.1.Beta1
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber
             Fix For: JBossMan.2.1.1.Beta2


The ManagedObject.hasDefaultName needs to be set to false when setting a @ManagementObjectID, otherwise the default name will be used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 11:44:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 2 Jun 2009 11:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-85) Don't override the
 @ManagementObjectID with a default name.
In-Reply-To: <21603131.1243957496670.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12115838.1243957496798.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Emanuel Muckenhuber resolved JBMAN-85.
--------------------------------------

    Resolution: Done


 Revision: 89669

> Don't override the @ManagementObjectID with a default name.
> -----------------------------------------------------------
>
>                 Key: JBMAN-85
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-85
>             Project: JBoss Managed
>          Issue Type: Bug
>    Affects Versions:  JBossMan.2.1.1.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossMan.2.1.1.Beta2
>
>
> The ManagedObject.hasDefaultName needs to be set to false when setting a @ManagementObjectID, otherwise the default name will be used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 12:05:57 2009
From: jira-events at lists.jboss.org (Hossein Attar (JIRA))
Date: Tue, 2 Jun 2009 12:05:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <27634648.1243958757871.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Hossein Attar commented on JBMESSAGING-1631:
--------------------------------------------

(On behalf of Victor)
The test  MDB is attached

> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 12:05:58 2009
From: jira-events at lists.jboss.org (Hossein Attar (JIRA))
Date: Tue, 2 Jun 2009 12:05:58 -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: <8760995.1243958758190.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Hossein Attar updated JBMESSAGING-1631:
---------------------------------------

    Attachment: TestRecommendationSentProcessorMDB.java


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 12:10:57 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 2 Jun 2009 12:10:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6983) Error configuring
 property: sessionIdAlphabet for WarDeployer
In-Reply-To: <16967894.1243494296657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14735809.1243959057369.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry updated JBAS-6983:
-----------------------------------

    Workaround Description: Move the <property name="sessionIdAlphabet">ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+-_</property> configuration element out of war-deployers-jboss-beans.xml and into the <bean name="WebServer"  class="org.jboss.web.tomcat.service.deployers.TomcatService"> bean in deploy/jbossweb.sar/META-INF/jboss-beans.xml.
                Workaround: [Workaround Exists]


Posted a workaround for those who need to configure this. The workaround is a kludge, but it works.

Remy, TBH the clustering code's use of it's own session id generation algorithm predates my involvement so I'm not familiar with the subtleties of why Ben went that way. I'll try and ping him. I know a year or two ago there were reports of session id collisions with the Tomcat algorithm and I never heard of any with the SessionIdGenerator, so I just left well enough alone. :)  I'd prefer though to get rid of SessionIdGenerator if possible.

Manuel, I'm curious as to why you wanted to configure this. If for future releases getting rid of SessionIdGenerator isn't practical, then changing to config via system property is a possibility. That's not as controllable via management tools like embedded console/Jopr/JON, so before doing that I'd like to get a better feel as to why/how often people would want to configure this.

> Error configuring property: sessionIdAlphabet for WarDeployer
> -------------------------------------------------------------
>
>                 Key: JBAS-6983
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6983
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: JBoss 5.0.1.GA or JBoss 5.1.0.GA
>            Reporter: Manuel Aznar Perez
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> At "server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml" when i uncomment "<property name="sessionIdAlphabet">" and run JBoss. Launch exception:
> 2009-05-28 08:34:34,670 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Configured: name=WarDeployer state=Instantiated
> java.lang.RuntimeException: Error configuring property: sessionIdAlphabet for WarDeployer
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112)
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85)
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44)
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
>         at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
>         at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
>         at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> That is because don't have "jboss-web-service.jar" in deployer. 
> This jar is in "deploy/jbossweb.sar".
> This is fixed copy jar file to deployer directory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 12:24:30 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Tue, 2 Jun 2009 12:24:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6942) Expose a
 testConnection operation via JMX
In-Reply-To: <25565782.1242746073015.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27803486.1243959885838.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer commented on JBAS-6942:
------------------------------------

Jesper, which MBean exposes the new operation and what is the name of the operation?

Also, did you expose the functionality via the Profile Service as well, or only JMX?

Thanks,
Ian


> Expose a testConnection operation via JMX
> -----------------------------------------
>
>                 Key: JBAS-6942
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6942
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>            Reporter: Heiko W. Rupp
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Hi, 
> would it be possible to expose a "tesConnection" method to JMX and/or the profile service, that basically tries to get a connection with the backend database and returns true if this was successful. The connection itself could directly be closed or put back into the pool. Obtaining the connection should always try to really hit the database and not just get a connection from the pool (unless the valid connection checking mechanism is used, which may or may not be configured on a datasource).
> Such an operation could be very handy for tools like Jopr. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 12:39:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 2 Jun 2009 12:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6942) Expose a
 testConnection operation via JMX
In-Reply-To: <25565782.1242746073015.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26526483.1243960796711.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jesper Pedersen commented on JBAS-6942:
---------------------------------------

Method is on JBossManagedConnectionPoolMBean

 boolean testConnection()

It is exposed through @ManagedOperation also.

> Expose a testConnection operation via JMX
> -----------------------------------------
>
>                 Key: JBAS-6942
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6942
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>            Reporter: Heiko W. Rupp
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Hi, 
> would it be possible to expose a "tesConnection" method to JMX and/or the profile service, that basically tries to get a connection with the backend database and returns true if this was successful. The connection itself could directly be closed or put back into the pool. Obtaining the connection should always try to really hit the database and not just get a connection from the pool (unless the valid connection checking mechanism is used, which may or may not be configured on a datasource).
> Such an operation could be very handy for tools like Jopr. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 13:13:57 2009
From: jira-events at lists.jboss.org (Hossein Attar (JIRA))
Date: Tue, 2 Jun 2009 13:13:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <4014849.1243962837486.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Hossein Attar commented on JBMESSAGING-1631:
--------------------------------------------

Howard:
I think your test case is right. Here are some details about our environment that may be useful.
We use java:/JmsXA as our connection factory
In hajndi-jms-ds.xml, we have
  <!-- JMS XA Resource adapter, use this to get transacted JMS in beans -->
  <tx-connection-factory>
    <jndi-name>JmsXA</jndi-name>
    <xa-transaction/>
    <rar-name>jms-ra.rar</rar-name>
    <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
    <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
    <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
    <max-pool-size>20</max-pool-size>
    <security-domain-and-application>JmsXARealm</security-domain-and-application>
  </tx-connection-factory>



and in  connection-factories-service.xml, we have 


   <!-- The default connection factory does not support automatic failover or load balancing-
        this is so we can maintain compatiblity with applications written for JBoss MQ which use this
        connection factory.
   -->     
   <mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"
      name="jboss.messaging.connectionfactory:service=ConnectionFactory"
      xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends optional-attribute-name="Connector">jboss.messaging:service=Connector,transport=bisocket</depends>
      <depends>jboss.messaging:service=PostOffice</depends>

      <attribute name="JNDIBindings">
         <bindings>
            <binding>/ConnectionFactory</binding>
            <binding>/XAConnectionFactory</binding>
            <binding>java:/ConnectionFactory</binding>
            <binding>java:/XAConnectionFactory</binding>
         </bindings>
      </attribute>
   </mbean>

   <!-- A clustered connection factory that supports automatic failover and load balancing of created
        connections.
        This factory is not suitable to be used by MDBs.
   -->
   <mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"
      name="jboss.messaging.connectionfactory:service=ClusteredConnectionFactory"
      xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends optional-attribute-name="Connector">jboss.messaging:service=Connector,transport=bisocket</depends>
      <depends>jboss.messaging:service=PostOffice</depends>

      <attribute name="JNDIBindings">
         <bindings>
            <binding>/ClusteredConnectionFactory</binding>
            <binding>/ClusteredXAConnectionFactory</binding>
            <binding>java:/ClusteredConnectionFactory</binding>
            <binding>java:/ClusteredXAConnectionFactory</binding>
         </bindings>
      </attribute>

      <attribute name="SupportsFailover">true</attribute>
      <attribute name="SupportsLoadBalancing">true</attribute>      
   </mbean>
   
   <!-- A connection factory with no JNDI bindings that is used in clustering to create the connections that
        pull messages from one node to another
   -->
   <mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"
      name="jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory"
      xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends optional-attribute-name="Connector">jboss.messaging:service=Connector,transport=bisocket</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
      <attribute name="SupportsFailover">false</attribute>
      <attribute name="SupportsLoadBalancing">false</attribute>      
   </mbean>
   

> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 13:42:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 2 Jun 2009 13:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1637)
	Interruption is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20608493.1243964576510.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox commented on JBMESSAGING-1637:
--------------------------------------

Ok, ok, you win :)

We'll get this done by the next release...

> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>             Fix For: 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 13:55:58 2009
From: jira-events at lists.jboss.org (Marius Bogoevici (JIRA))
Date: Tue, 2 Jun 2009 13:55:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBSPRING-6) Modify the Maven
 build file to create the spring.deployer
In-Reply-To: <9759864.1242189598333.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29791617.1243965358589.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Marius Bogoevici resolved JBSPRING-6.
-------------------------------------

    Resolution: Done


> Modify the Maven build file to create the spring.deployer
> ---------------------------------------------------------
>
>                 Key: JBSPRING-6
>                 URL: https://jira.jboss.org/jira/browse/JBSPRING-6
>             Project: JBoss Spring Integration
>          Issue Type: Feature Request
>            Reporter: Marius Bogoevici
>            Assignee: Marius Bogoevici
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 13:55:59 2009
From: jira-events at lists.jboss.org (Marius Bogoevici (JIRA))
Date: Tue, 2 Jun 2009 13:55:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSPRING-6) Modify the Maven
 build file to create the spring.deployer
In-Reply-To: <9759864.1242189598333.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16524959.1243965359341.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Marius Bogoevici closed JBSPRING-6.
-----------------------------------



> Modify the Maven build file to create the spring.deployer
> ---------------------------------------------------------
>
>                 Key: JBSPRING-6
>                 URL: https://jira.jboss.org/jira/browse/JBSPRING-6
>             Project: JBoss Spring Integration
>          Issue Type: Feature Request
>            Reporter: Marius Bogoevici
>            Assignee: Marius Bogoevici
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 17:47:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 2 Jun 2009 17:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6844) Remove "embedded"
	module
In-Reply-To: <30880585.1241013647667.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7583882.1243979276935.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger resolved JBAS-6844.
---------------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> Remove "embedded" module
> ------------------------
>
>                 Key: JBAS-6844
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6844
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The "embedded" module is now legacy and should be pulled from the source tree and moved under an embedded-legacy component.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 18:14:56 2009
From: jira-events at lists.jboss.org (Mike Van Noord (JIRA))
Date: Tue, 2 Jun 2009 18:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6996)
 ClassNotFoundException for array types in JDK6
Message-ID: <4729180.1243980896777.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClassNotFoundException for array types in JDK6
----------------------------------------------

                 Key: JBAS-6996
                 URL: https://jira.jboss.org/jira/browse/JBAS-6996
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMX
    Affects Versions: JBossAS-5.1.0.GA
         Environment: JDK 1.6
            Reporter: Mike Van Noord
            Assignee: Dimitris Andreadis


org.jboss.mx.server.InvocationContext uses the ClassLoader.loadClass() call rather than Class.forName().  Due to a behavioral change from Java 5 to Java 6, this call now throws a ClassNotFoundException when that class is of an array type, e.g. "[Ljava.lang.String;".

The situation is the same as the one described here: https://jira.jboss.org/jira/browse/JBRULES-1553

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 20:01:00 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Tue, 2 Jun 2009 20:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-124) Implement SAMLV2.0
	validation
Message-ID: <26312958.1243987260389.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement SAMLV2.0 validation
-----------------------------

                 Key: JBID-124
                 URL: https://jira.jboss.org/jira/browse/JBID-124
             Project: JBoss Identity
          Issue Type: Sub-task
          Components: Identity-Federation
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: IDFED-1.0.0.alpha3


The SAML token provider must be able to validate the assertions it generates. This involves validating the digital signature and also the assertion validity period (lifetime).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 22:54:56 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 2 Jun 2009 22:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-328) support Java
 attributes and elements
In-Reply-To: <26091683.1241701314495.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15548526.1243997696713.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Koen Aers resolved GPD-328.
---------------------------

    Resolution: Done


> support Java attributes and elements
> ------------------------------------
>
>                 Key: GPD-328
>                 URL: https://jira.jboss.org/jira/browse/GPD-328
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.CR1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> attributes: class, method, var
> elements: field, arg

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 23:28:56 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 2 Jun 2009 23:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-345) XML namespaces are
 not consistent between GPD and the engine
In-Reply-To: <25020237.1243434353653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33541158.1243999736885.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Koen Aers resolved GPD-345.
---------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.CR1
       Resolution: Duplicate Issue


duplicate of GPD-338

> XML namespaces are not consistent between GPD and the engine
> ------------------------------------------------------------
>
>                 Key: GPD-345
>                 URL: https://jira.jboss.org/jira/browse/GPD-345
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>         Environment: GPD from jbpm-4.0.0.Beta2
>            Reporter: Alexis Seigneurin
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.CR1
>
>
> The graphical designer and the process engine do not use the same XML namespace. GPD uses http://jbpm.org/4/jpdl whereas the engine uses http://jbpm.org/4.0/jpdl.
> The consequence is that a process created with the designer does not work in the engine. You get errors like these:
> 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: start>
> 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: decision>
> 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: state>
> 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: state>
> 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: state>
> 2009-05-27 16:19:09,258 INFO [org.jbpm.pvm.internal.repository.RepositorySessionImpl] - <errors during deployment of deployment(96): 
>   error: no start activity in process >

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 23:28:57 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 2 Jun 2009 23:28:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-348) jdpl.xml xmlns
	altered wrong
In-Reply-To: <11700206.1243712216785.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8514537.1243999737389.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Koen Aers resolved GPD-348.
---------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.CR1
       Resolution: Duplicate Issue


duplicate of GPD-338

> jdpl.xml xmlns altered wrong
> ----------------------------
>
>                 Key: GPD-348
>                 URL: https://jira.jboss.org/jira/browse/GPD-348
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM jPDL Designer 4.0.0.beta2
>            Reporter: Johan Kumps
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.0.CR1
>
>
> When changing the layout in the diagram view, the xmlns="http://jbpm.org/4.0/jpdl" is altered to xmlns="http://jbpm.org/4/jpdl" causing :
> org.jbpm.api.JbpmException:
>   error: no start activity in process
>         at org.jbpm.pvm.internal.xml.ProblemList.getJbpmException(ProblemList.java:169)
>         at org.jbpm.pvm.internal.xml.ProblemList.getJbpmException(ProblemList.java:142)
>         at org.jbpm.pvm.internal.repository.RepositorySessionImpl.deploy(RepositorySessionImpl.java:58)
>         at org.jbpm.pvm.internal.cmd.DeployCmd.execute(DeployCmd.java:47)
>         at org.jbpm.pvm.internal.cmd.DeployCmd.execute(DeployCmd.java:33)
>         at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
>         at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:54)
>         at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:54)
>         at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
>         at org.jbpm.pvm.internal.repository.DeploymentImpl.deploy(DeploymentImpl.java:81)
>         at org.jbpm.pvm.internal.ant.JbpmDeployTask.deployFile(JbpmDeployTask.java:108)
>         at org.jbpm.pvm.internal.ant.JbpmDeployTask.execute(JbpmDeployTask.java:60)
>         at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
>         at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
>         at org.apache.tools.ant.Task.perform(Task.java:348)
>         at org.apache.tools.ant.Target.execute(Target.java:357)
>         at org.apache.tools.ant.Target.performTasks(Target.java:385)
>         at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
>         at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
>         at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
>         at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
>         at org.apache.tools.ant.Main.runBuild(Main.java:758)
>         at org.apache.tools.ant.Main.startAnt(Main.java:217)
>         at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
>         at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 23:31:07 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 2 Jun 2009 23:31:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <26384952.1243999867672.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1631:
-----------------------------------------

Hi Hossein,

Thanks a lot for the info!

Howard


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 02:31:56 2009
From: jira-events at lists.jboss.org (Manuel Aznar Perez (JIRA))
Date: Wed, 3 Jun 2009 02:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6983) Error configuring
 property: sessionIdAlphabet for WarDeployer
In-Reply-To: <16967894.1243494296657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19094856.1244010716778.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Manuel Aznar Perez commented on JBAS-6983:
------------------------------------------

A customer needs that.

I need remove character "+" because an old big customer application pass sessionId at the GET parameter, then character "+" == space blank. 

I changed character "+" to "*". Then it works fine.

It's migration Tomcat to JBossWeb. This at Tomcat don't fail.

> Error configuring property: sessionIdAlphabet for WarDeployer
> -------------------------------------------------------------
>
>                 Key: JBAS-6983
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6983
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: JBoss 5.0.1.GA or JBoss 5.1.0.GA
>            Reporter: Manuel Aznar Perez
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> At "server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml" when i uncomment "<property name="sessionIdAlphabet">" and run JBoss. Launch exception:
> 2009-05-28 08:34:34,670 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Configured: name=WarDeployer state=Instantiated
> java.lang.RuntimeException: Error configuring property: sessionIdAlphabet for WarDeployer
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112)
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85)
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44)
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
>         at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
>         at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
>         at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> That is because don't have "jboss-web-service.jar" in deployer. 
> This jar is in "deploy/jbossweb.sar".
> This is fixed copy jar file to deployer directory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 03:50:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 03:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-837) Add failure simulation
 capabilities to Simulator
In-Reply-To: <8863048.1224253881092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26245055.1244015457752.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban updated JGRP-837:
--------------------------

    Fix Version/s: 3.x


> Add failure simulation capabilities to Simulator 
> -------------------------------------------------
>
>                 Key: JGRP-837
>                 URL: https://jira.jboss.org/jira/browse/JGRP-837
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>            Priority: Minor
>             Fix For: 3.x
>
>
> The Simulator can be used to test protocol layers in isolation. Multiple Simulator instances can be configured so that they model a multicast group.
> In its present state, messages are transported from one Simulator instance to another by the send_thread, which moves messages from send_queue to recv_queue in a reliable fashion.  Futhermore, all Simulators perform at the same speed. I'd like to use the Simulator to additionally simulate failures, in order to check the robustness of the protocols. In particular, i'd like to model:
> * dropped, reordered, corrupted messages
> * failed processors ('crash' failure)
> * network partitions
> * slow processes
> This JIRA issue will track progress on this and allow for discussion.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 03:50:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 03:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-912) Failed to parse the
 jgroups.xml file
In-Reply-To: <13018129.1235533725240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6604282.1244015457601.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban updated JGRP-912:
--------------------------

    Fix Version/s: 2.6.11
                   2.8


> Failed to parse the jgroups.xml file
> ------------------------------------
>
>                 Key: JGRP-912
>                 URL: https://jira.jboss.org/jira/browse/JGRP-912
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.8
>         Environment: jdk 6, jboss cache 3.0.2 GA, jgroup 2.6.8, wind0ws XP
>            Reporter: sridhar reddy
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: GridJbossCacheManager.java, jboss-cache.xml, jgroups.xml
>
>
> I have the following jboss cache xml as below
> [code]
> <?xml version="1.0" encoding="UTF-8"?>
> <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:jboss:jbosscache-core:config:3.0">
> <locking isolationLevel="READ_COMMITTED"
> lockParentForChildInsertRemove="false" lockAcquisitionTimeout="20000"
> nodeLockingScheme="mvcc" writeSkewCheck="false"
> concurrencyLevel="500" />
> <transaction
> transactionManagerLookupClass="org.jboss.cache.transaction.GenericTransactionManagerLookup"
> syncRollbackPhase="false" syncCommitPhase="false" />
> <eviction wakeUpInterval="500">
> <default algorithmClass="org.jboss.cache.eviction.LRUAlgorithm"
> eventQueueSize="200000">
> <property name="maxNodes" value="5000" />
> <property name="timeToLive" value="1000" />
> </default>
> <region name="/org/jboss/data1">
> <property name="timeToLive" value="2000" />
> </region>
> <region name="/org/jboss/data2"
> algorithmClass="org.jboss.cache.eviction.FIFOAlgorithm"
> eventQueueSize="100000">
> <property name="maxNodes" value="3000" />
> <property name="minTimeToLive" value="4000" />
> </region>
> </eviction>
> <clustering mode="replication" >
> <jgroupsConfig configFile="C:/workspace/GridJBCache3/src/config/jgroups.xml" />
> </clustering>
> <loaders passivation="false" shared="false">
> <preload>
> <node fqn="/" />
> </preload>
> <loader class="org.jboss.cache.loader.JDBCCacheLoader"
> async="true" fetchPersistentState="true" ignoreModifications="true"
> purgeOnStartup="true">
> <properties>
> cache.jdbc.table.name=jbosscache
> cache.jdbc.table.create=true
> cache.jdbc.table.drop=false
> cache.jdbc.table.primarykey=jbosscache_pk
> cache.jdbc.fqn.column=fqn
> cache.jdbc.fqn.type=varchar(255)
> cache.jdbc.node.column=node
> cache.jdbc.node.type=bytea
> cache.jdbc.parent.column=parent
> cache.jdbc.driver=org.postgresql.Driver
> cache.jdbc.url=jdbc:postgresql://localhost:5432/facts7
> cache.jdbc.user=f7tms
> cache.jdbc.password=f7tms
> </properties>
> </loader>
> </loaders>
> </jbosscache>
> [/code]
> and jgroups.xml file as below
> [code]
> <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="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="discard"
> oob_thread_pool.enabled="true" oob_thread_pool.min_threads="1"
> oob_thread_pool.max_threads="8"
> oob_thread_pool.keep_alive_time="5000"
> oob_thread_pool.queue_enabled="false"
> oob_thread_pool.queue_max_size="100"
> oob_thread_pool.rejection_policy="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="3000"
> 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 /
> -->
> </config>
> [/code]
> My code start the cache as
> [code]
> package org.gridgain.examples.jbosscache;
> import java.io.File;
> import org.jboss.cache.Cache;
> import org.jboss.cache.CacheFactory;
> import org.jboss.cache.DefaultCacheFactory;
> import org.jboss.cache.Fqn;
> import org.jboss.cache.Node;
> import org.jboss.cache.config.Configuration;
> import org.jboss.cache.config.parsing.XmlConfigurationParser;
> import org.jgroups.JChannelFactory;
> public final class GridJbossCacheManager {
>     /** Cache configuration path relative to GridGain installation. */
>     public static final String CACHE_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jboss-cache.xml";
>     /** JGroups configuration path relative to GridGain installation. */
>     public static final String JGROUPS_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jgroups.xml";
>     /** JBoss Cache instance. */
>     private Cache<Long, String> cache = null;
>     /** Cache node for caching example data. */
>     private Node<Long, String> cacheRoot = null;
>     /** Singleton instance. */
>     private static GridJbossCacheManager instance = new GridJbossCacheManager();
>     /**
>      * Gets singleton.
>      *
>      * @return Singleton.
>      */
>     public static GridJbossCacheManager getInstance() {
>         return instance;
>     }
>     /**
>      * Ensure singleton.
>      */
>     private GridJbossCacheManager() {
>         // No-op.
>     }
>    
>     public void start() throws GridException {
>         File cacheCfg = new File(CACHE_CFG_PATH);
>         if (cacheCfg == null) {
>             throw new GridException("Failed to find cache configuration file: " + CACHE_CFG_PATH);
>         }
>         File jgroupsCfg = new File(JGROUPS_CFG_PATH);
>         if (jgroupsCfg == null) {
>             throw new GridException("Failed to find jgroups configuration: " + JGROUPS_CFG_PATH);
>         }
>         // Make sure JBoss Cache and GridGain are on the same "wave length".
>         JChannelFactory factory = new JChannelFactory(); //null;
>         try {
>          //factory = new JChannelFactory(jgroupsCfg);
>             factory.setMultiplexerConfig(jgroupsCfg.getCanonicalPath());
>         }
>         catch (Exception e) {
>             throw new GridException("Failed to start Data Manager.", e);
>         }
>         try {
>             XmlConfigurationParser parser = new XmlConfigurationParser();
>             // Start JBoss Cache cache with shared JGroups configuration.
>             Configuration svrCfg = parser.parseFile(cacheCfg.getCanonicalPath());
>             svrCfg.getRuntimeConfig().setMuxChannelFactory(factory);
>             CacheFactory<Long, String> dataFactory = DefaultCacheFactory.getInstance();
>             // Instantiate and start JBoss Cache.
>             cache = dataFactory.createCache(svrCfg);
>             // Cache node for storing example data.
>             cacheRoot = cache.getRoot().addChild(Fqn.fromString("/"));
>         }
>         catch (Exception e) {
>             throw new GridException("Failed to start Data Manager.", e);
>         }
>         System.out.println("JBoss Cache data manager started.");
>     }
>    
> }
> [/code]
> When i ran this program i am getting the following error
> [code]
> Exception in thread "main"
> Exception:
> ----------
> >>> Type: java.lang.Exception
> >>> Message: failed parsing C:\workspace\GridJBCache3\src\config\jgroups.xml
> >>> Stack trace:
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:216)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> Caused By:
> ----------
> >>> Type: java.io.IOException
> >>> Message: invalid XML configuration: XML protocol stack configuration does not start with a '<config>' element; maybe the XML configuration needs to be converted to the new format ?
> use 'java org.jgroups.conf.XmlConfigurator <old XML file> -new_format' to do so
> >>> Stack trace:
> >>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:476)
> >>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:462)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:213)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> [/code]
> Now i have added the
> [code]
> <protocol_stacks>
> <stack name="udp"
> description="Default: IP multicast based stack, with flow control and message bundling">
> [/code]
> to jgroups.xml. When i ran the program, its giving the following error.
> [code]
> log4j:WARN No appenders could be found for logger (org.jboss.cache.util.FileLookup).
> log4j:WARN Please initialize the log4j system properly.
> Exception in thread "main" org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
> at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:148)
> at org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(ComponentRegistry.java:1005)
> at org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegistry.java:775)
> at org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java:629)
> at org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocationDelegate.java:344)
> at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:121)
> at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:105)
> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:148)
> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:144)
> ... 9 more
> Caused by: org.jboss.cache.CacheException: Failed to create multiplexed channel using stack null
> at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:353)
> at org.jboss.cache.RPCManagerImpl.initialiseChannelAndRpcDispatcher(RPCManagerImpl.java:267)
> at org.jboss.cache.RPCManagerImpl.start(RPCManagerImpl.java:167)
> ... 14 more
> Caused by: java.lang.IllegalArgumentException: stack name and service ID have to be non null
> at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:336)
> at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:328)
> at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:349)
> ... 16 more
> [/code] 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 03:59:56 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Wed, 3 Jun 2009 03:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-88)
 ProfileServiceBootstrap: Failed to build ManagedDeployment
In-Reply-To: <10128448.1244015996530.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30283758.1244015996712.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ondrej Medek updated JBBOOT-88:
-------------------------------

    Attachment: boot.log


> ProfileServiceBootstrap: Failed to build ManagedDeployment
> ----------------------------------------------------------
>
>                 Key: JBBOOT-88
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-88
>             Project: JBoss Bootstrap
>          Issue Type: Bug
>         Environment: JBoss AS 5.1.0, WinXP, jdk 1.6.0u13
>            Reporter: Ondrej Medek
>            Assignee: Andrew Lee Rubinger
>         Attachments: boot.log
>
>
> I see two exception in my boot.log: DEBUG [ProfileServiceBootstrap] Failed to build ManagedDeployment for:
> 1) AbstractKernelDeployment at 1cd427a{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml installed=true beanFactories=[AbstractBeanMetaData at c791f4{name=VFSCache bean=null properties=[realCache, permanentRoots] constructor=AbstractConstructorMetaData at 198defc{parameters=[null] factoryClass=org.jboss.virtual.spi.cache.VFSCacheFactory factoryMethod=getInstance} autowireCandidate=true start=AbstractLifecycleMetaData at 1579a30{ whenRequired=ControllerState at 3f58bb{Start} parameters= }}, AbstractBeanMetaData at da9067{name=VfsNamesExceptionHandler bean=org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler properties= constructor=AbstractConstructorMetaData at 13e9934{parameters=[java.lang.String]} autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 2) AbstractKernelDeployment at 17044c5{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml installed=true beanFactories=[AbstractBeanMetaData at 1b2e44d{name=LogBridgeHandler bean=org.jboss.logbridge.LogBridgeHandler properties= constructor=null autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 03:59:56 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Wed, 3 Jun 2009 03:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-88)
 ProfileServiceBootstrap: Failed to build ManagedDeployment
Message-ID: <10128448.1244015996530.JavaMail.jira@cloud.prod.atl2.jboss.com>

ProfileServiceBootstrap: Failed to build ManagedDeployment
----------------------------------------------------------

                 Key: JBBOOT-88
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-88
             Project: JBoss Bootstrap
          Issue Type: Bug
         Environment: JBoss AS 5.1.0, WinXP, jdk 1.6.0u13
            Reporter: Ondrej Medek
            Assignee: Andrew Lee Rubinger
         Attachments: boot.log

I see two exception in my boot.log: DEBUG [ProfileServiceBootstrap] Failed to build ManagedDeployment for:

1) AbstractKernelDeployment at 1cd427a{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml installed=true beanFactories=[AbstractBeanMetaData at c791f4{name=VFSCache bean=null properties=[realCache, permanentRoots] constructor=AbstractConstructorMetaData at 198defc{parameters=[null] factoryClass=org.jboss.virtual.spi.cache.VFSCacheFactory factoryMethod=getInstance} autowireCandidate=true start=AbstractLifecycleMetaData at 1579a30{ whenRequired=ControllerState at 3f58bb{Start} parameters= }}, AbstractBeanMetaData at da9067{name=VfsNamesExceptionHandler bean=org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler properties= constructor=AbstractConstructorMetaData at 13e9934{parameters=[java.lang.String]} autowireCandidate=true}]}
org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)


2) AbstractKernelDeployment at 17044c5{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml installed=true beanFactories=[AbstractBeanMetaData at 1b2e44d{name=LogBridgeHandler bean=org.jboss.logbridge.LogBridgeHandler properties= constructor=null autowireCandidate=true}]}
org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 04:20:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 04:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-984) JGroups can not
 parse IPV6 literals in TCPPING protocol configuration
In-Reply-To: <7188979.1242741125294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33004478.1244017256805.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban commented on JGRP-984:
-------------------------------

This works for me, I tried it under 2.4 head. Note that [::1][7810] is *NOT* a valid address, the angle brackets need to be removed ! ::1[7810] works.

Please attach instructions on how to reproduce this, and re-open the case if the problem persists.

> JGroups can not parse IPV6 literals in TCPPING protocol configuration
> ---------------------------------------------------------------------
>
>                 Key: JGRP-984
>                 URL: https://jira.jboss.org/jira/browse/JGRP-984
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.6
>            Reporter: Brian Stansberry
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> ON JBPAPP-2013 Dominik Pospisil reports the IPv6 address parsing fix in 2.4.6 doesn't handle TCPPING:
> Both
> <TCPPING initial_hosts="::1[7810],fec0::f101:21a:a0ff:fea0:d745[7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> and
> <TCPPING initial_hosts="[::1][7810],[fec0::f101:21a:a0ff:fea0:d745][7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> fails with:
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "::1"
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "fec0::f101:21a:a0ff:fea0:d745"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 04:24:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 04:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33340540.1244017496545.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban commented on JGRP-978:
-------------------------------

The problem is that I don't know if JGroups runs in an IPv6-only environment, and we have to pick an address.

The workaround of course is to set the diagnostics address to an IPv6 multicast address, or to disable probing altogether.

Richard: do you know of multicast addresses which are valid for both IPv4 and IPv6 ? And why isn't an IPv4 multicast address automatically converted to an IPv6 address in an IPv6-only environment ?

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 04:40:57 2009
From: jira-events at lists.jboss.org (Victor Starenky (JIRA))
Date: Wed, 3 Jun 2009 04:40:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <21042994.1244018457345.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Victor Starenky commented on JBMESSAGING-1631:
----------------------------------------------

I think one important thing to reproduce the problem is to cause client/server failover due to timeouts. This could happen either because of unreliable network or due to high cpu usage / lack of resources. If both servers are pretty much idle and sit on a good network it's quite unlikely we'll see the problem.

Another difference between your test case and our environment is that we\re sending messages to the queue from the same application farmed across both servers. We're using both stateless EJB beans to get the XA clustered factory injected by the container for sending messages and just a jndi lookup. I don't think all of this matters as the problems seem to be on a receiving side but still thought I would mention this. 

> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 05:00:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 3 Jun 2009 05:00:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <2193375.1244019657196.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1631:
-----------------------------------------

Thanks Victor. One thing I can do to trigger failover is reduce the ping timeout in remoting configuration, that worked well in my dealing with JBMESSAGING-1456.



> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 05:07:56 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 3 Jun 2009 05:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-986) FLUSH: relax event
 sequencing for a joining member
In-Reply-To: <16765612.1244019962699.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13754192.1244020076890.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Vladimir Blagojevic updated JGRP-986:
-------------------------------------

    Description: 
There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a switch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This switch was introduced to always enforce a strict order between view, unblock and message M. 

If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.

  was:
There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a latch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If a message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This latch was introduced to always enforce a strict order between view, unblock and message M. 

If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.



> FLUSH: relax event sequencing for a joining member
> --------------------------------------------------
>
>                 Key: JGRP-986
>                 URL: https://jira.jboss.org/jira/browse/JGRP-986
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.10, 2.8
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>
> There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a switch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This switch was introduced to always enforce a strict order between view, unblock and message M. 
> If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 05:06:02 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 3 Jun 2009 05:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-986) FLUSH: relax event
 sequencing for a joining member
Message-ID: <16765612.1244019962699.JavaMail.jira@cloud.prod.atl2.jboss.com>

FLUSH: relax event sequencing for a joining member
--------------------------------------------------

                 Key: JGRP-986
                 URL: https://jira.jboss.org/jira/browse/JGRP-986
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.6.10, 2.8
            Reporter: Vladimir Blagojevic
            Assignee: Vladimir Blagojevic
             Fix For: 2.6.11, 2.8


There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a latch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If a message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This latch was introduced to always enforce a strict order between view, unblock and message M. 

If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 05:13:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 05:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-964) shared_transport
 concurrency
 failure - starting NotificationBusses at the same time causes "timer cannot
 be retrieved from protocol stack"
In-Reply-To: <3477014.1240858726835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28791810.1244020436777.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban resolved JGRP-964.
---------------------------

    Resolution: Done


Fixed by wrapping JChannel.init() with a class-wide lock. This has no impact on regular startup

> shared_transport concurrency failure - starting NotificationBusses at the same time causes "timer cannot be retrieved from protocol stack"
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-964
>                 URL: https://jira.jboss.org/jira/browse/JGRP-964
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Win2000, JVM = JRockit 6, although reproducible with test app under Windows XP and Java 6u13.
>            Reporter: Edward Kuns
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: CoordinationBus.xml, JGroupsTest.java, JGroupsTest.java, log4j.xml
>
>
> I have an application that starts four jgroups NotificationBus's that all share the same UDP transport (with          singleton_name="...") but are otherwise distinct.  Recently, the application started to fail to start with the following stack signature:
> 2009-04-27 13:56:50,425 -0500 ERROR [JGroupsTest] - Exception running bus
> org.jgroups.ChannelException: unable to setup the protocol stack: timer cannot be retrieved from protocol stack
> 	at org.jgroups.JChannel.init(JChannel.java:1574)
> 	at org.jgroups.JChannel.<init>(JChannel.java:257)
> 	at org.jgroups.JChannel.<init>(JChannel.java:240)
> 	at org.jgroups.blocks.NotificationBus.<init>(NotificationBus.java:69)
> 	at JGroupsTest$1.run(JGroupsTest.java:25)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: timer cannot be retrieved from protocol stack
> 	at org.jgroups.protocols.Discovery.init(Discovery.java:98)
> 	at org.jgroups.protocols.PING.init(PING.java:84)
> 	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:641)
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:468)
> 	at org.jgroups.JChannel.init(JChannel.java:1570)
> 	... 5 more
> I created a test application that does nothing but start these four busses, and if I start them simultaneously, I can always reproduce the above error.  I will attach the test application.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 05:15:58 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 3 Jun 2009 05:15:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-912) Failed to parse the
 jgroups.xml file
In-Reply-To: <13018129.1235533725240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23484090.1244020558549.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Vladimir Blagojevic commented on JGRP-912:
------------------------------------------

Something does not seem right about this snippet here. Please check how you comment elements and use XML editor to verify xml document is well formed!

<FRAG2 frag_size="60000" />
-
<!-- pbcast.STREAMING_STATE_TRANSFER /
-->
<pbcast.STATE_TRANSFER />
-
<!-- pbcast.FLUSH /
--> 

> Failed to parse the jgroups.xml file
> ------------------------------------
>
>                 Key: JGRP-912
>                 URL: https://jira.jboss.org/jira/browse/JGRP-912
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.8
>         Environment: jdk 6, jboss cache 3.0.2 GA, jgroup 2.6.8, wind0ws XP
>            Reporter: sridhar reddy
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: GridJbossCacheManager.java, jboss-cache.xml, jgroups.xml
>
>
> I have the following jboss cache xml as below
> [code]
> <?xml version="1.0" encoding="UTF-8"?>
> <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:jboss:jbosscache-core:config:3.0">
> <locking isolationLevel="READ_COMMITTED"
> lockParentForChildInsertRemove="false" lockAcquisitionTimeout="20000"
> nodeLockingScheme="mvcc" writeSkewCheck="false"
> concurrencyLevel="500" />
> <transaction
> transactionManagerLookupClass="org.jboss.cache.transaction.GenericTransactionManagerLookup"
> syncRollbackPhase="false" syncCommitPhase="false" />
> <eviction wakeUpInterval="500">
> <default algorithmClass="org.jboss.cache.eviction.LRUAlgorithm"
> eventQueueSize="200000">
> <property name="maxNodes" value="5000" />
> <property name="timeToLive" value="1000" />
> </default>
> <region name="/org/jboss/data1">
> <property name="timeToLive" value="2000" />
> </region>
> <region name="/org/jboss/data2"
> algorithmClass="org.jboss.cache.eviction.FIFOAlgorithm"
> eventQueueSize="100000">
> <property name="maxNodes" value="3000" />
> <property name="minTimeToLive" value="4000" />
> </region>
> </eviction>
> <clustering mode="replication" >
> <jgroupsConfig configFile="C:/workspace/GridJBCache3/src/config/jgroups.xml" />
> </clustering>
> <loaders passivation="false" shared="false">
> <preload>
> <node fqn="/" />
> </preload>
> <loader class="org.jboss.cache.loader.JDBCCacheLoader"
> async="true" fetchPersistentState="true" ignoreModifications="true"
> purgeOnStartup="true">
> <properties>
> cache.jdbc.table.name=jbosscache
> cache.jdbc.table.create=true
> cache.jdbc.table.drop=false
> cache.jdbc.table.primarykey=jbosscache_pk
> cache.jdbc.fqn.column=fqn
> cache.jdbc.fqn.type=varchar(255)
> cache.jdbc.node.column=node
> cache.jdbc.node.type=bytea
> cache.jdbc.parent.column=parent
> cache.jdbc.driver=org.postgresql.Driver
> cache.jdbc.url=jdbc:postgresql://localhost:5432/facts7
> cache.jdbc.user=f7tms
> cache.jdbc.password=f7tms
> </properties>
> </loader>
> </loaders>
> </jbosscache>
> [/code]
> and jgroups.xml file as below
> [code]
> <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="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="discard"
> oob_thread_pool.enabled="true" oob_thread_pool.min_threads="1"
> oob_thread_pool.max_threads="8"
> oob_thread_pool.keep_alive_time="5000"
> oob_thread_pool.queue_enabled="false"
> oob_thread_pool.queue_max_size="100"
> oob_thread_pool.rejection_policy="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="3000"
> 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 /
> -->
> </config>
> [/code]
> My code start the cache as
> [code]
> package org.gridgain.examples.jbosscache;
> import java.io.File;
> import org.jboss.cache.Cache;
> import org.jboss.cache.CacheFactory;
> import org.jboss.cache.DefaultCacheFactory;
> import org.jboss.cache.Fqn;
> import org.jboss.cache.Node;
> import org.jboss.cache.config.Configuration;
> import org.jboss.cache.config.parsing.XmlConfigurationParser;
> import org.jgroups.JChannelFactory;
> public final class GridJbossCacheManager {
>     /** Cache configuration path relative to GridGain installation. */
>     public static final String CACHE_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jboss-cache.xml";
>     /** JGroups configuration path relative to GridGain installation. */
>     public static final String JGROUPS_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jgroups.xml";
>     /** JBoss Cache instance. */
>     private Cache<Long, String> cache = null;
>     /** Cache node for caching example data. */
>     private Node<Long, String> cacheRoot = null;
>     /** Singleton instance. */
>     private static GridJbossCacheManager instance = new GridJbossCacheManager();
>     /**
>      * Gets singleton.
>      *
>      * @return Singleton.
>      */
>     public static GridJbossCacheManager getInstance() {
>         return instance;
>     }
>     /**
>      * Ensure singleton.
>      */
>     private GridJbossCacheManager() {
>         // No-op.
>     }
>    
>     public void start() throws GridException {
>         File cacheCfg = new File(CACHE_CFG_PATH);
>         if (cacheCfg == null) {
>             throw new GridException("Failed to find cache configuration file: " + CACHE_CFG_PATH);
>         }
>         File jgroupsCfg = new File(JGROUPS_CFG_PATH);
>         if (jgroupsCfg == null) {
>             throw new GridException("Failed to find jgroups configuration: " + JGROUPS_CFG_PATH);
>         }
>         // Make sure JBoss Cache and GridGain are on the same "wave length".
>         JChannelFactory factory = new JChannelFactory(); //null;
>         try {
>          //factory = new JChannelFactory(jgroupsCfg);
>             factory.setMultiplexerConfig(jgroupsCfg.getCanonicalPath());
>         }
>         catch (Exception e) {
>             throw new GridException("Failed to start Data Manager.", e);
>         }
>         try {
>             XmlConfigurationParser parser = new XmlConfigurationParser();
>             // Start JBoss Cache cache with shared JGroups configuration.
>             Configuration svrCfg = parser.parseFile(cacheCfg.getCanonicalPath());
>             svrCfg.getRuntimeConfig().setMuxChannelFactory(factory);
>             CacheFactory<Long, String> dataFactory = DefaultCacheFactory.getInstance();
>             // Instantiate and start JBoss Cache.
>             cache = dataFactory.createCache(svrCfg);
>             // Cache node for storing example data.
>             cacheRoot = cache.getRoot().addChild(Fqn.fromString("/"));
>         }
>         catch (Exception e) {
>             throw new GridException("Failed to start Data Manager.", e);
>         }
>         System.out.println("JBoss Cache data manager started.");
>     }
>    
> }
> [/code]
> When i ran this program i am getting the following error
> [code]
> Exception in thread "main"
> Exception:
> ----------
> >>> Type: java.lang.Exception
> >>> Message: failed parsing C:\workspace\GridJBCache3\src\config\jgroups.xml
> >>> Stack trace:
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:216)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> Caused By:
> ----------
> >>> Type: java.io.IOException
> >>> Message: invalid XML configuration: XML protocol stack configuration does not start with a '<config>' element; maybe the XML configuration needs to be converted to the new format ?
> use 'java org.jgroups.conf.XmlConfigurator <old XML file> -new_format' to do so
> >>> Stack trace:
> >>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:476)
> >>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:462)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:213)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> [/code]
> Now i have added the
> [code]
> <protocol_stacks>
> <stack name="udp"
> description="Default: IP multicast based stack, with flow control and message bundling">
> [/code]
> to jgroups.xml. When i ran the program, its giving the following error.
> [code]
> log4j:WARN No appenders could be found for logger (org.jboss.cache.util.FileLookup).
> log4j:WARN Please initialize the log4j system properly.
> Exception in thread "main" org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
> at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:148)
> at org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(ComponentRegistry.java:1005)
> at org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegistry.java:775)
> at org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java:629)
> at org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocationDelegate.java:344)
> at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:121)
> at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:105)
> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:148)
> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:144)
> ... 9 more
> Caused by: org.jboss.cache.CacheException: Failed to create multiplexed channel using stack null
> at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:353)
> at org.jboss.cache.RPCManagerImpl.initialiseChannelAndRpcDispatcher(RPCManagerImpl.java:267)
> at org.jboss.cache.RPCManagerImpl.start(RPCManagerImpl.java:167)
> ... 14 more
> Caused by: java.lang.IllegalArgumentException: stack name and service ID have to be non null
> at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:336)
> at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:328)
> at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:349)
> ... 16 more
> [/code] 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 05:43:07 2009
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Wed, 3 Jun 2009 05:43:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2406) Chapter 3.4
 'Configuring the
 Email Service' incorrectly references CMS workflow notifications
Message-ID: <7844852.1244022187159.JavaMail.jira@cloud.prod.atl2.jboss.com>

Chapter 3.4 'Configuring the Email Service' incorrectly references CMS workflow notifications
---------------------------------------------------------------------------------------------

                 Key: JBPORTAL-2406
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2406
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Reference Guide
    Affects Versions: 2.7.1 Final, 2.6.7 Final
            Reporter: Martin Putz


The first paragraph in Chapter 3.4 'Configuring the Email Service' incorrectly references CMS workflow notifications:

"The email service, for example, can be used to verify a user's email address when a user subscribes, or for CMS workflow notifications."

The CMS approval workflow is now based upon GUI operations instead of email notifications. Therefore, the last part of the sentence above is misleading and should be removed. The same applies to the EPP docs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 06:04:00 2009
From: jira-events at lists.jboss.org (Andrzej Smolinski (JIRA))
Date: Wed, 3 Jun 2009 06:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1650) Need
 EL-replacement within
 @RemoteBinding.clientBindUrl so connect addresses are not hardcoded
In-Reply-To: <13986808.1229942454491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25032118.1244023440776.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470371#action_12470371 ] 

Andrzej Smolinski commented on EJBTHREE-1650:
---------------------------------------------

Is there any workaround? If not when it is planned to be resolved?

> Need EL-replacement within @RemoteBinding.clientBindUrl so connect addresses are not hardcoded
> ----------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1650
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1650
>             Project: EJB 3.0
>          Issue Type: Feature Request
>         Environment: CentOS release 5 (Final)
>            Reporter: amar slimane
>            Assignee: Andrew Lee Rubinger
>
> With JBoss5.0.0.Beta4, it's possible to specify 'jboss.bind.address' as a remoting binding with setting 'clientBindUrl' to 0.0.0.0  :
> @RemoteBindings({
>   @RemoteBinding( clientBindUrl="socket://3873:",       jndiBinding = "jndiBind1") ,
>   @RemoteBinding( clientBindUrl="sslsocket://3843:",  jndiBinding = "jndiBind2") ,
>   @RemoteBinding( clientBindUrl="https://0.0.0.0:8443/servlet-invoker/SSLServerInvokerServlet",  jndiBinding = "jndiBind3") ,
> })
> This don't work with JBoss5.0.0.GA and  it's impossible to have multiple remoting binds  for an EJB.
> It's critical for our application and we don't know if there is a workaround.
> This issue is  probably relative to https://jira.jboss.org/jira/browse/EJBTHREE-1610

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 06:25:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 3 Jun 2009 06:25:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12442811.1244024756537.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

On a given host, we can have three possible cases of coexistence between IPv4 and IPv6: IPv4 only support, IPv6 only support or dual-stack IPv4 and IPv6 support. I have read informally that dual-stack support is not available on certain OSs (e.g. Windows XP, Windows 2003, OpenBSD)

On dual stack machines, IPv6 has some special features for supporting the transition from IPv4 to IPv6. One of these is IPv4-mapped addresses, where an IPv4 address can be used together with the IPv6 API. This allows IPv4 clients to talk to IPv6 servers, for example. It also allows managing IPv4 clients and servers from an IPv6 interface. The IPv6 API is used at the transport level (e.g. TCP, UDP) when opening a socket. At the network level, however, the packets are shipped using IPv4.  

I don't know of (and I suspect there is not) a multicast address which is valid for both IPv4 and IPv6. 
Why isn't an IPv4 multicast address converted automatically to an IPv6 address in an IPv6-only environment? Possibly because multicast in IPv6 is scoped and so it would be difficult to know which scope to use for a given IPv4 multicast address.

I guess this is mainly an issue of making all the defaults for IP addresses configurable, so the user has at least the option of implementing the workaround. It may be just a lot of unnecessary and error prone work to try to have JGroups detect the particular case of coexistence between IPv4 and IPv6 that it happens to be in.

  

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 07:19:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 3 Jun 2009 07:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6997) Log a message on the
 console when
 the Log4jService scheduled task picks up changes to jboss-log4j
 configuration
Message-ID: <10819216.1244027996481.JavaMail.jira@cloud.prod.atl2.jboss.com>

Log a message on the console when the Log4jService scheduled task picks up changes to jboss-log4j configuration
---------------------------------------------------------------------------------------------------------------

                 Key: JBAS-6997
                 URL: https://jira.jboss.org/jira/browse/JBAS-6997
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Logging
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: jaikiran pai
            Assignee: jaikiran pai
            Priority: Minor
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


AS-4.x used to log a message to the console to indicate that any dynamic changes to the jboss-log4j.xml have been picked up. This message is now logged at DEBUG level and hence does not (by default) appear on console. Logging this at INFO level would help users to see a confirmation that their changes to jboss-log4j.xml have been picked up dynamically.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 07:21:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 3 Jun 2009 07:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6997) Log a message on the
 console when
 the Log4jService scheduled task picks up changes to jboss-log4j.xml
 configuration
In-Reply-To: <10819216.1244027996481.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7583082.1244028116599.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai updated JBAS-6997:
-------------------------------

    Summary: Log a message on the console when the Log4jService scheduled task picks up changes to jboss-log4j.xml configuration  (was: Log a message on the console when the Log4jService scheduled task picks up changes to jboss-log4j configuration)


> Log a message on the console when the Log4jService scheduled task picks up changes to jboss-log4j.xml configuration
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6997
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6997
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> AS-4.x used to log a message to the console to indicate that any dynamic changes to the jboss-log4j.xml have been picked up. This message is now logged at DEBUG level and hence does not (by default) appear on console. Logging this at INFO level would help users to see a confirmation that their changes to jboss-log4j.xml have been picked up dynamically.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:17:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 3 Jun 2009 08:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6997) Log a message on
 the console
 when the Log4jService scheduled task picks up changes to jboss-log4j.xml
 configuration
In-Reply-To: <10819216.1244027996481.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9484142.1244031476467.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai resolved JBAS-6997.
--------------------------------

    Resolution: Done


Similar to JBoss AS-4.x, upon reconfiguration, a INFO level message will be logged:

16:33:42,840 INFO  [Log4jService$URLWatchTimerTask] Configuring from URL: resource:jboss-log4j.xml

> Log a message on the console when the Log4jService scheduled task picks up changes to jboss-log4j.xml configuration
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6997
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6997
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> AS-4.x used to log a message to the console to indicate that any dynamic changes to the jboss-log4j.xml have been picked up. This message is now logged at DEBUG level and hence does not (by default) appear on console. Logging this at INFO level would help users to see a confirmation that their changes to jboss-log4j.xml have been picked up dynamically.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:32:10 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 08:32:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10382056.1244032332314.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban commented on JGRP-978:
-------------------------------

Thanks for the clarification. Since the diagnostics address is configurable, should we close this issue ?

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:32:13 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 3 Jun 2009 08:32:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBID-124) Implement WS-T SAML
 Token Profile:: SAMLV2.0 validation
In-Reply-To: <26312958.1243987260389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6825958.1244032333079.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBID-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470391#action_12470391 ] 

Anil Saldhana commented on JBID-124:
------------------------------------

XMLSignatureUtil and there is XMLTimeUtil for assertion validity checking.

Maybe we need an utility for assertion alone: such as checking if the validity exists etc. (I will add it today).
AssertionExpiredException is the exception.

> Implement WS-T SAML Token Profile:: SAMLV2.0 validation
> -------------------------------------------------------
>
>                 Key: JBID-124
>                 URL: https://jira.jboss.org/jira/browse/JBID-124
>             Project: JBoss Identity
>          Issue Type: Sub-task
>          Components: Identity-Federation
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha3
>
>
> The SAML token provider must be able to validate the assertions it generates. This involves validating the digital signature and also the assertion validity period (lifetime).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:32:05 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 3 Jun 2009 08:32:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-124) Implement WS-T SAML
 Token Profile:: SAMLV2.0 validation
In-Reply-To: <26312958.1243987260389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9309802.1244032325218.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated JBID-124:
-------------------------------

    Summary: Implement WS-T SAML Token Profile:: SAMLV2.0 validation  (was: Implement SAMLV2.0 validation)


> Implement WS-T SAML Token Profile:: SAMLV2.0 validation
> -------------------------------------------------------
>
>                 Key: JBID-124
>                 URL: https://jira.jboss.org/jira/browse/JBID-124
>             Project: JBoss Identity
>          Issue Type: Sub-task
>          Components: Identity-Federation
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha3
>
>
> The SAML token provider must be able to validate the assertions it generates. This involves validating the digital signature and also the assertion validity period (lifetime).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:42:19 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 3 Jun 2009 08:42:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-125) AssertionUtil
Message-ID: <27295921.1244032939265.JavaMail.jira@cloud.prod.atl2.jboss.com>

AssertionUtil
-------------

                 Key: JBID-125
                 URL: https://jira.jboss.org/jira/browse/JBID-125
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.alpha3


Utility to deal with assertions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:42:28 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 08:42:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-912) Failed to parse the
 jgroups.xml file
In-Reply-To: <13018129.1235533725240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26584708.1244032948761.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban closed JGRP-912.
-------------------------

    Resolution: Rejected


This is a JBossCache issue, not a JGroups issue ! Please submit to the JBC JIRA

> Failed to parse the jgroups.xml file
> ------------------------------------
>
>                 Key: JGRP-912
>                 URL: https://jira.jboss.org/jira/browse/JGRP-912
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.8
>         Environment: jdk 6, jboss cache 3.0.2 GA, jgroup 2.6.8, wind0ws XP
>            Reporter: sridhar reddy
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: GridJbossCacheManager.java, jboss-cache.xml, jgroups.xml
>
>
> I have the following jboss cache xml as below
> [code]
> <?xml version="1.0" encoding="UTF-8"?>
> <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:jboss:jbosscache-core:config:3.0">
> <locking isolationLevel="READ_COMMITTED"
> lockParentForChildInsertRemove="false" lockAcquisitionTimeout="20000"
> nodeLockingScheme="mvcc" writeSkewCheck="false"
> concurrencyLevel="500" />
> <transaction
> transactionManagerLookupClass="org.jboss.cache.transaction.GenericTransactionManagerLookup"
> syncRollbackPhase="false" syncCommitPhase="false" />
> <eviction wakeUpInterval="500">
> <default algorithmClass="org.jboss.cache.eviction.LRUAlgorithm"
> eventQueueSize="200000">
> <property name="maxNodes" value="5000" />
> <property name="timeToLive" value="1000" />
> </default>
> <region name="/org/jboss/data1">
> <property name="timeToLive" value="2000" />
> </region>
> <region name="/org/jboss/data2"
> algorithmClass="org.jboss.cache.eviction.FIFOAlgorithm"
> eventQueueSize="100000">
> <property name="maxNodes" value="3000" />
> <property name="minTimeToLive" value="4000" />
> </region>
> </eviction>
> <clustering mode="replication" >
> <jgroupsConfig configFile="C:/workspace/GridJBCache3/src/config/jgroups.xml" />
> </clustering>
> <loaders passivation="false" shared="false">
> <preload>
> <node fqn="/" />
> </preload>
> <loader class="org.jboss.cache.loader.JDBCCacheLoader"
> async="true" fetchPersistentState="true" ignoreModifications="true"
> purgeOnStartup="true">
> <properties>
> cache.jdbc.table.name=jbosscache
> cache.jdbc.table.create=true
> cache.jdbc.table.drop=false
> cache.jdbc.table.primarykey=jbosscache_pk
> cache.jdbc.fqn.column=fqn
> cache.jdbc.fqn.type=varchar(255)
> cache.jdbc.node.column=node
> cache.jdbc.node.type=bytea
> cache.jdbc.parent.column=parent
> cache.jdbc.driver=org.postgresql.Driver
> cache.jdbc.url=jdbc:postgresql://localhost:5432/facts7
> cache.jdbc.user=f7tms
> cache.jdbc.password=f7tms
> </properties>
> </loader>
> </loaders>
> </jbosscache>
> [/code]
> and jgroups.xml file as below
> [code]
> <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="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="discard"
> oob_thread_pool.enabled="true" oob_thread_pool.min_threads="1"
> oob_thread_pool.max_threads="8"
> oob_thread_pool.keep_alive_time="5000"
> oob_thread_pool.queue_enabled="false"
> oob_thread_pool.queue_max_size="100"
> oob_thread_pool.rejection_policy="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="3000"
> 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 /
> -->
> </config>
> [/code]
> My code start the cache as
> [code]
> package org.gridgain.examples.jbosscache;
> import java.io.File;
> import org.jboss.cache.Cache;
> import org.jboss.cache.CacheFactory;
> import org.jboss.cache.DefaultCacheFactory;
> import org.jboss.cache.Fqn;
> import org.jboss.cache.Node;
> import org.jboss.cache.config.Configuration;
> import org.jboss.cache.config.parsing.XmlConfigurationParser;
> import org.jgroups.JChannelFactory;
> public final class GridJbossCacheManager {
>     /** Cache configuration path relative to GridGain installation. */
>     public static final String CACHE_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jboss-cache.xml";
>     /** JGroups configuration path relative to GridGain installation. */
>     public static final String JGROUPS_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jgroups.xml";
>     /** JBoss Cache instance. */
>     private Cache<Long, String> cache = null;
>     /** Cache node for caching example data. */
>     private Node<Long, String> cacheRoot = null;
>     /** Singleton instance. */
>     private static GridJbossCacheManager instance = new GridJbossCacheManager();
>     /**
>      * Gets singleton.
>      *
>      * @return Singleton.
>      */
>     public static GridJbossCacheManager getInstance() {
>         return instance;
>     }
>     /**
>      * Ensure singleton.
>      */
>     private GridJbossCacheManager() {
>         // No-op.
>     }
>    
>     public void start() throws GridException {
>         File cacheCfg = new File(CACHE_CFG_PATH);
>         if (cacheCfg == null) {
>             throw new GridException("Failed to find cache configuration file: " + CACHE_CFG_PATH);
>         }
>         File jgroupsCfg = new File(JGROUPS_CFG_PATH);
>         if (jgroupsCfg == null) {
>             throw new GridException("Failed to find jgroups configuration: " + JGROUPS_CFG_PATH);
>         }
>         // Make sure JBoss Cache and GridGain are on the same "wave length".
>         JChannelFactory factory = new JChannelFactory(); //null;
>         try {
>          //factory = new JChannelFactory(jgroupsCfg);
>             factory.setMultiplexerConfig(jgroupsCfg.getCanonicalPath());
>         }
>         catch (Exception e) {
>             throw new GridException("Failed to start Data Manager.", e);
>         }
>         try {
>             XmlConfigurationParser parser = new XmlConfigurationParser();
>             // Start JBoss Cache cache with shared JGroups configuration.
>             Configuration svrCfg = parser.parseFile(cacheCfg.getCanonicalPath());
>             svrCfg.getRuntimeConfig().setMuxChannelFactory(factory);
>             CacheFactory<Long, String> dataFactory = DefaultCacheFactory.getInstance();
>             // Instantiate and start JBoss Cache.
>             cache = dataFactory.createCache(svrCfg);
>             // Cache node for storing example data.
>             cacheRoot = cache.getRoot().addChild(Fqn.fromString("/"));
>         }
>         catch (Exception e) {
>             throw new GridException("Failed to start Data Manager.", e);
>         }
>         System.out.println("JBoss Cache data manager started.");
>     }
>    
> }
> [/code]
> When i ran this program i am getting the following error
> [code]
> Exception in thread "main"
> Exception:
> ----------
> >>> Type: java.lang.Exception
> >>> Message: failed parsing C:\workspace\GridJBCache3\src\config\jgroups.xml
> >>> Stack trace:
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:216)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> Caused By:
> ----------
> >>> Type: java.io.IOException
> >>> Message: invalid XML configuration: XML protocol stack configuration does not start with a '<config>' element; maybe the XML configuration needs to be converted to the new format ?
> use 'java org.jgroups.conf.XmlConfigurator <old XML file> -new_format' to do so
> >>> Stack trace:
> >>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:476)
> >>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:462)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:213)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> [/code]
> Now i have added the
> [code]
> <protocol_stacks>
> <stack name="udp"
> description="Default: IP multicast based stack, with flow control and message bundling">
> [/code]
> to jgroups.xml. When i ran the program, its giving the following error.
> [code]
> log4j:WARN No appenders could be found for logger (org.jboss.cache.util.FileLookup).
> log4j:WARN Please initialize the log4j system properly.
> Exception in thread "main" org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
> at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:148)
> at org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(ComponentRegistry.java:1005)
> at org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegistry.java:775)
> at org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java:629)
> at org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocationDelegate.java:344)
> at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:121)
> at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:105)
> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:148)
> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:144)
> ... 9 more
> Caused by: org.jboss.cache.CacheException: Failed to create multiplexed channel using stack null
> at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:353)
> at org.jboss.cache.RPCManagerImpl.initialiseChannelAndRpcDispatcher(RPCManagerImpl.java:267)
> at org.jboss.cache.RPCManagerImpl.start(RPCManagerImpl.java:167)
> ... 14 more
> Caused by: java.lang.IllegalArgumentException: stack name and service ID have to be non null
> at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:336)
> at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:328)
> at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:349)
> ... 16 more
> [/code] 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:44:33 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 3 Jun 2009 08:44:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBID-124) Implement WS-T SAML
 Token Profile:: SAMLV2.0 validation
In-Reply-To: <26312958.1243987260389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22071469.1244033076459.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBID-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470394#action_12470394 ] 

Anil Saldhana commented on JBID-124:
------------------------------------

JBID-125 has a new AssertionUtil to check for expiry

> Implement WS-T SAML Token Profile:: SAMLV2.0 validation
> -------------------------------------------------------
>
>                 Key: JBID-124
>                 URL: https://jira.jboss.org/jira/browse/JBID-124
>             Project: JBoss Identity
>          Issue Type: Sub-task
>          Components: Identity-Federation
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha3
>
>
> The SAML token provider must be able to validate the assertions it generates. This involves validating the digital signature and also the assertion validity period (lifetime).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:46:08 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 3 Jun 2009 08:46:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-125) AssertionUtil
In-Reply-To: <27295921.1244032939265.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17949087.1244033168308.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed JBID-125.
------------------------------

    Resolution: Done


> AssertionUtil
> -------------
>
>                 Key: JBID-125
>                 URL: https://jira.jboss.org/jira/browse/JBID-125
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha3
>
>
> Utility to deal with assertions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:06:32 2009
From: jira-events at lists.jboss.org (Tobias Frech (JIRA))
Date: Wed, 3 Jun 2009 09:06:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBOOT-86) Reduce logging
 noise by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21515141.1244034399086.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470396#action_12470396 ] 

Tobias Frech commented on JBBOOT-86:
------------------------------------

If you do remove the JBOSS_HOME part from the output, why not simply prefix the output with JBOSS_HOME/.
That would be correct but still terse.

We would get:

JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
Bootstrap: JBOSS_HOME /server/default/conf/bootstrap.xml
Common Base: JBOSS_HOME /common/
Common Library: JBOSS_HOME /common/lib/
Server Name: JBOSS_HOME /default
Server Base: JBOSS_HOME /server/
Server Library: JBOSS_HOME /server/default/lib/
Server Config: JBOSS_HOME /default/conf/
Server Home: JBOSS_HOME /server/default/
Server Data: JBOSS_HOME /server/default/data
Server Log: JBOSS_HOME /default/log/
Server Temp: JBOSS_HOME /default/tmp 


If someone overrides any of the locations the JBOSS_HOME is automatically omitted and the attention is drawn to that entry as well.
You could have a helper class, that scans the JVM-environment for some variables and replaces the URL part with that variable name.


> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Andrew Lee Rubinger
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:08:11 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 09:08:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-987) Make many classes
	immutable
Message-ID: <31204033.1244034493328.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make many classes immutable
---------------------------

                 Key: JGRP-987
                 URL: https://jira.jboss.org/jira/browse/JGRP-987
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.x


Currently, a lot of classes could be immutable if it wasn't for the readFrom() method to initialize itself from an input stream.

However, if we had a factory, which reads and constructs immutable instances of classes, then we could turn a lot of classes into immutable classes, for example all headers should be immutable.

The code for marshalling and unmarshalling could be generated, e.g. based on an XML description of the data layout of a class.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:08:30 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 09:08:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-965) Message: headers are
	not copied
In-Reply-To: <3496327.1240914106581.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23975221.1244034512895.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban updated JGRP-965:
--------------------------

    Fix Version/s: 3.x
                       (was: 2.8)


> Message: headers are not copied
> -------------------------------
>
>                 Key: JGRP-965
>                 URL: https://jira.jboss.org/jira/browse/JGRP-965
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.x
>
>
> Message.copy() uses Headers.copy() which does *not* copy the headers but just uses refs. This might cause unintended side effects, investigate whether this is okay or not.
> Example: we have a message in a retransmission table. We might copy it on retransmissio and change a header, that change will then be made in the original header.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:10:22 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 09:10:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-340) GossipRouter: major
	overhaul
In-Reply-To: <730198.1160401841970.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31023446.1244034624813.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban resolved JGRP-340.
---------------------------

    Resolution: Done


UDP support was left out because we're waiting for NIO in JDK 7, this will be done later

> GossipRouter: major overhaul
> ----------------------------
>
>                 Key: JGRP-340
>                 URL: https://jira.jboss.org/jira/browse/JGRP-340
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.4
>            Reporter: Bela Ban
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.8
>
>         Attachments: BCTdiff.txt, CTdiff.txt, GCdiff.txt, GossipClient.java, GossipRouter.java, GRdiff.txt
>
>
> Things to be done:
> - Use of Streamable rather than Externalizable
> - Currently we use 1 thread per request rather than a thread pool, e.g. Executor !
> - Better logging and diagnostics (JMX)
> - Use of NIO to prevent the 1 thread/client scalability issue
> - GossipClient and RouterStub should use common, shared code to communicate with the GossipRouter, currently there are exceptions because these 2 classes don't even use the same network format ! Besides, we can refactor redundant code into a common superclass
> - Use of ConnectionTable(NIO) ?
> - Add configuration options for GossipRouter's sockets, e.g. send/receive buffer size, nagling, keep_alive etc
> - Support of UDP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:12:16 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 3 Jun 2009 09:12:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6970330.1244034739089.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

Before closing, should we add something to the docs about this? The fact that diagnostics addresses are configurable, how to change the defaults, and that this may be required when running in an IPv6 environment?  

If you don't change the defaults for diagnostics, you get the unenviable situation where the user intends to use IPv6 and takes care to change his bind and multicast address, but diagnostics still uses IPv4. If the user has only adjusted his IPv6 firewall, the IPv4 diagnostics packets might not get through, and he may wonder why JGroups works but probe does not.

The firewall issue may come into play with other non-diagnostics IPv4 defaults which are getting picked up, if there are any. 
 



> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:14:08 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 3 Jun 2009 09:14:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13352332.1244034850497.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

And what about the errors above trying to bind to virtual interfaces? 

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:20:18 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 09:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <748502.1244035218274.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban commented on JGRP-978:
-------------------------------

A stupid idea: why don't we pick an IPv4 multicast address *and* an IPv6 multicast address for the diagnostics address ? First we try to bind to the IPv4 mcast address, if this fails we fall back to binding to the IPv6 mcast address. Probe then also mcasts packets to both the IPv4 and IPv6 addresses...

Of course, we should suppress some of the errors that will inevitable show up...

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:37:57 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 3 Jun 2009 09:37:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26643849.1244036277505.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

Yes, if we are going to use defaults, we probably need defaults for both Pv4 and IPv6 now.

But doesn't this leave us in the same position as before: a user binds and sets mcast to IPv6 addresses, but diagnostics will try IPv4 first and succeed, leaving a JGroups instance using both IPv4 and IPv6.

Can't we use the bind address and/or mcast address which the user supplies (or does not) to choose which type of diagnostics address (IPv4 or IPv6) to use?  So, when JGroups starts up, we set a flag isIPv6, as with isLinux, isHPUX, etc., based on the bind and/or multicast address specified. The only time we would have a problem is when they typed in an IPv4 bind address with an IPv6 multicast address, say, and that might reasonably generate an error?




> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:45:36 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 09:45:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4181544.1244036739468.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban commented on JGRP-978:
-------------------------------

OK, so you want to do the following: if the bind_addr is (not null) and is an Inet6Address, then pick the IPv6 default for the diagnostics multicast address, else fall back to the IPv4 address. I think that's fine. Can you do that ?

What do we do on the probe.sh side if -mcast_addr is not specified on the command line ? By default try the IPv4 mcast address ? Or both the IPv4 and IPv6 default mcast addresses ?

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:55:01 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 3 Jun 2009 09:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-986) FLUSH: relax event
 sequencing for a joining member
In-Reply-To: <16765612.1244019962699.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6597142.1244037305268.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Vladimir Blagojevic resolved JGRP-986.
--------------------------------------

    Resolution: Done


Added javadoc to ExtendedMembershipListener


Resolved on HEAD (JGroups 2.8)

Revision Changes Path
1.134 +1 -4 JGroups/src/org/jgroups/protocols/pbcast/FLUSH.java



Resolved on 2.6 Branch (Included in 2.6.11 release)

1.82.2.22 +0 -7 JGroups/src/org/jgroups/protocols/pbcast/FLUSH.java

> FLUSH: relax event sequencing for a joining member
> --------------------------------------------------
>
>                 Key: JGRP-986
>                 URL: https://jira.jboss.org/jira/browse/JGRP-986
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.10, 2.8
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>
> There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a switch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This switch was introduced to always enforce a strict order between view, unblock and message M. 
> If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:59:32 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 3 Jun 2009 09:59:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3759133.1244037572825.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

I'll check it out. May take a couple of days, as i've got EAP stuff to do.

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:59:45 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 3 Jun 2009 09:59:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-984) JGroups can not
 parse IPV6 literals in TCPPING protocol configuration
In-Reply-To: <7188979.1242741125294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17114115.1244037588440.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry commented on JGRP-984:
---------------------------------------

Thanks. I copied your comment to the original issue JBPAPP-2013 and asked Dominik to reply here if there is anything further.

> JGroups can not parse IPV6 literals in TCPPING protocol configuration
> ---------------------------------------------------------------------
>
>                 Key: JGRP-984
>                 URL: https://jira.jboss.org/jira/browse/JGRP-984
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.6
>            Reporter: Brian Stansberry
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> ON JBPAPP-2013 Dominik Pospisil reports the IPv6 address parsing fix in 2.4.6 doesn't handle TCPPING:
> Both
> <TCPPING initial_hosts="::1[7810],fec0::f101:21a:a0ff:fea0:d745[7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> and
> <TCPPING initial_hosts="[::1][7810],[fec0::f101:21a:a0ff:fea0:d745][7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> fails with:
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "::1"
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "fec0::f101:21a:a0ff:fea0:d745"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:10:19 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 3 Jun 2009 10:10:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBOOT-88)
 ProfileServiceBootstrap: Failed to build ManagedDeployment
In-Reply-To: <10128448.1244015996530.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19566180.1244038227259.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBBOOT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470420#action_12470420 ] 

Andrew Lee Rubinger commented on JBBOOT-88:
-------------------------------------------

What are the steps taken to reproduce the above?  Is this simply on boot?

This should likely be filed under JBAS project; ProfileServiceBootstrap is part of the AS "system" module.



> ProfileServiceBootstrap: Failed to build ManagedDeployment
> ----------------------------------------------------------
>
>                 Key: JBBOOT-88
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-88
>             Project: JBoss Bootstrap
>          Issue Type: Bug
>         Environment: JBoss AS 5.1.0, WinXP, jdk 1.6.0u13
>            Reporter: Ondrej Medek
>            Assignee: Andrew Lee Rubinger
>         Attachments: boot.log
>
>
> I see two exception in my boot.log: DEBUG [ProfileServiceBootstrap] Failed to build ManagedDeployment for:
> 1) AbstractKernelDeployment at 1cd427a{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml installed=true beanFactories=[AbstractBeanMetaData at c791f4{name=VFSCache bean=null properties=[realCache, permanentRoots] constructor=AbstractConstructorMetaData at 198defc{parameters=[null] factoryClass=org.jboss.virtual.spi.cache.VFSCacheFactory factoryMethod=getInstance} autowireCandidate=true start=AbstractLifecycleMetaData at 1579a30{ whenRequired=ControllerState at 3f58bb{Start} parameters= }}, AbstractBeanMetaData at da9067{name=VfsNamesExceptionHandler bean=org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler properties= constructor=AbstractConstructorMetaData at 13e9934{parameters=[java.lang.String]} autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 2) AbstractKernelDeployment at 17044c5{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml installed=true beanFactories=[AbstractBeanMetaData at 1b2e44d{name=LogBridgeHandler bean=org.jboss.logbridge.LogBridgeHandler properties= constructor=null autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:36:40 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Wed, 3 Jun 2009 10:36:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBOOT-88)
 ProfileServiceBootstrap: Failed to build ManagedDeployment
In-Reply-To: <10128448.1244015996530.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <558162.1244039802016.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBBOOT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470431#action_12470431 ] 

Ondrej Medek commented on JBBOOT-88:
------------------------------------

Yes, just simple boot of the "default" server configuration, i.e. bin\run.bat, that's it.

How to move this bug to the proper project?

> ProfileServiceBootstrap: Failed to build ManagedDeployment
> ----------------------------------------------------------
>
>                 Key: JBBOOT-88
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-88
>             Project: JBoss Bootstrap
>          Issue Type: Bug
>         Environment: JBoss AS 5.1.0, WinXP, jdk 1.6.0u13
>            Reporter: Ondrej Medek
>            Assignee: Andrew Lee Rubinger
>         Attachments: boot.log
>
>
> I see two exception in my boot.log: DEBUG [ProfileServiceBootstrap] Failed to build ManagedDeployment for:
> 1) AbstractKernelDeployment at 1cd427a{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml installed=true beanFactories=[AbstractBeanMetaData at c791f4{name=VFSCache bean=null properties=[realCache, permanentRoots] constructor=AbstractConstructorMetaData at 198defc{parameters=[null] factoryClass=org.jboss.virtual.spi.cache.VFSCacheFactory factoryMethod=getInstance} autowireCandidate=true start=AbstractLifecycleMetaData at 1579a30{ whenRequired=ControllerState at 3f58bb{Start} parameters= }}, AbstractBeanMetaData at da9067{name=VfsNamesExceptionHandler bean=org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler properties= constructor=AbstractConstructorMetaData at 13e9934{parameters=[java.lang.String]} autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 2) AbstractKernelDeployment at 17044c5{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml installed=true beanFactories=[AbstractBeanMetaData at 1b2e44d{name=LogBridgeHandler bean=org.jboss.logbridge.LogBridgeHandler properties= constructor=null autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:49:23 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 3 Jun 2009 10:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1842)
 ClusteredIsLocalInterceptor finds unstarted beans
Message-ID: <10481921.1244040566021.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClusteredIsLocalInterceptor finds unstarted beans
-------------------------------------------------

                 Key: EJBTHREE-1842
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1842
             Project: EJB 3.0
          Issue Type: Bug
          Components: interceptors
    Affects Versions: AS 4.2.2.GA
            Reporter: Brian Stansberry
            Assignee: Paul Ferraro


ClusteredIsLocalInterceptor determines whether a bean is available locally by checking the Ejb3Registry. Problem is beans are registered early in the deployment process, before they are started.

In the related forum thread pawel.wyrwinski reports how this particularly causes problems when an @Depends("jboss.ha:service=HASingletonDeployer,type=Barrier") annotation is used to make a bean act as an HASingleton. The bean is included in the Ejb3Registry on all nodes but is only started on one.

A logically obvious solution would be to check whether the target container is started before invoking locally. Unfortunately, AFAICT Container and its subclasses do not expose any method to support such a check.

Pawel reported this against 4.2.2 so that the "Affects Version" I used, but a quick code check leads me to believe it still exists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:51:54 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 3 Jun 2009 10:51:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14621886.1244040716830.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Charles Crouch updated JBAS-6808:
---------------------------------

    Priority: Critical  (was: Major)


> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:52:51 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 10:52:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6939) after stopping a
 Topic or Queue
 via the stop operation, calling getRunState() on the corresponding
 component returns RunState.RUNNING, rather than RunState.STOPPED
In-Reply-To: <3464546.1242671225528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31560105.1244040780232.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6939:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> after stopping a Topic or Queue via the stop operation, calling getRunState() on the corresponding component returns RunState.RUNNING, rather than RunState.STOPPED
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6939
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6939
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Ian Springer
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:53:42 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 10:53:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6960) once a Topic or
 Queue has been
 stopped via the 'stop' operation, none of its operations or properties
 work, and thus it cannot be restarted using the 'start' operation
In-Reply-To: <11989891.1242832445240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19229992.1244040830281.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6960:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> once a Topic or Queue has been stopped via the 'stop' operation, none of its operations or properties work, and thus it cannot be restarted using the 'start' operation
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6960
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6960
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Ian Springer
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:55:26 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 10:55:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6242) invoke() for
 "listFormattedSubPoolStatistics" ManagedOperation on datasources and
 connection factory ManagedComponents returns a MetaValue with the wrong
 MetaType
In-Reply-To: <18716075.1227550606927.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27741102.1244040928841.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6242:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


I'm not sure if this is still an issue. We need to try to reproduce it w/ the latest bits.



> invoke() for "listFormattedSubPoolStatistics" ManagedOperation on datasources and connection factory ManagedComponents returns a MetaValue with the wrong MetaType
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6242
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6242
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBAS5 Hudson build dated 200811210604
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This is another case of the data not matching the metadata.
> operation.getReturnType() returns a MutableCompositeMetaType w/ typeName java.lang.Object. However, invoke() is returning a SimpleMetaType.STRING (with value e.g. "Sub Pool Statistics: \nSub Pool Count: 0\n------------------------------------------------------\n"). 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:56:28 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 3 Jun 2009 10:56:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-6998)
 ProfileServiceBootstrap: Failed to build ManagedDeployment
In-Reply-To: <10128448.1244015996530.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16341337.1244040991594.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger moved JBBOOT-88 to JBAS-6998:
-------------------------------------------------

     Project: JBoss Application Server  (was: JBoss Bootstrap)
         Key: JBAS-6998  (was: JBBOOT-88)
    Security: Public


> ProfileServiceBootstrap: Failed to build ManagedDeployment
> ----------------------------------------------------------
>
>                 Key: JBAS-6998
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6998
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBoss AS 5.1.0, WinXP, jdk 1.6.0u13
>            Reporter: Ondrej Medek
>            Assignee: Andrew Lee Rubinger
>         Attachments: boot.log
>
>
> I see two exception in my boot.log: DEBUG [ProfileServiceBootstrap] Failed to build ManagedDeployment for:
> 1) AbstractKernelDeployment at 1cd427a{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml installed=true beanFactories=[AbstractBeanMetaData at c791f4{name=VFSCache bean=null properties=[realCache, permanentRoots] constructor=AbstractConstructorMetaData at 198defc{parameters=[null] factoryClass=org.jboss.virtual.spi.cache.VFSCacheFactory factoryMethod=getInstance} autowireCandidate=true start=AbstractLifecycleMetaData at 1579a30{ whenRequired=ControllerState at 3f58bb{Start} parameters= }}, AbstractBeanMetaData at da9067{name=VfsNamesExceptionHandler bean=org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler properties= constructor=AbstractConstructorMetaData at 13e9934{parameters=[java.lang.String]} autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 2) AbstractKernelDeployment at 17044c5{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml installed=true beanFactories=[AbstractBeanMetaData at 1b2e44d{name=LogBridgeHandler bean=org.jboss.logbridge.LogBridgeHandler properties= constructor=null autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:57:53 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 10:57:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-5452)
 ManagementView.getDeployment
 should always at least return a structural view of a deployment
In-Reply-To: <8840076.1208274234767.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1706745.1244041075881.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-5452:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> ManagementView.getDeployment should always at least return a structural view of a deployment
> --------------------------------------------------------------------------------------------
>
>                 Key: JBAS-5452
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5452
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services, ProfileService
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently the ManagementView.getDeployment(String name, DeploymentPhase phase) api requires a deployment to have @ManagementDeployment/@ManagementObject/@ManagementComponent annotations to build any type of view of the deployment. There should be a basic structure view returned in the absence of any @ManagementObject/@ManagementComponent info. It would just be the structure view with a ManagedDeployment graph that mirrors the StructureMetaData.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:58:46 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 3 Jun 2009 10:58:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6998)
 ProfileServiceBootstrap: Failed to build ManagedDeployment
In-Reply-To: <10128448.1244015996530.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8861294.1244041134429.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger commented on JBAS-6998:
-------------------------------------------

Recommend opening a topic in the AS5 User's Forum: http://www.jboss.org/index.html?module=bb&op=viewforum&f=287

> ProfileServiceBootstrap: Failed to build ManagedDeployment
> ----------------------------------------------------------
>
>                 Key: JBAS-6998
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6998
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBoss AS 5.1.0, WinXP, jdk 1.6.0u13
>            Reporter: Ondrej Medek
>            Assignee: Andrew Lee Rubinger
>         Attachments: boot.log
>
>
> I see two exception in my boot.log: DEBUG [ProfileServiceBootstrap] Failed to build ManagedDeployment for:
> 1) AbstractKernelDeployment at 1cd427a{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml installed=true beanFactories=[AbstractBeanMetaData at c791f4{name=VFSCache bean=null properties=[realCache, permanentRoots] constructor=AbstractConstructorMetaData at 198defc{parameters=[null] factoryClass=org.jboss.virtual.spi.cache.VFSCacheFactory factoryMethod=getInstance} autowireCandidate=true start=AbstractLifecycleMetaData at 1579a30{ whenRequired=ControllerState at 3f58bb{Start} parameters= }}, AbstractBeanMetaData at da9067{name=VfsNamesExceptionHandler bean=org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler properties= constructor=AbstractConstructorMetaData at 13e9934{parameters=[java.lang.String]} autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 2) AbstractKernelDeployment at 17044c5{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml installed=true beanFactories=[AbstractBeanMetaData at 1b2e44d{name=LogBridgeHandler bean=org.jboss.logbridge.LogBridgeHandler properties= constructor=null autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:02:11 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 11:02:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6524) BeanMetaDataICF
 logging many exceptions at debug while retrieving properties
In-Reply-To: <17044868.1234985744567.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17253558.1244041333921.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6524:
-------------------------------

    Complexity: Low
        Labels: EmbJopr1_3 ProfileService  (was: )


> BeanMetaDataICF logging many exceptions at debug while retrieving properties
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-6524
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6524
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.Beta1
>         Environment: jboss-5.1.x-r84398.zip
>            Reporter: Charles Crouch
>            Assignee: Scott M Stark
>            Priority: Optional
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: BeanMetaDataICF-exceptions.log
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> I'm seeing many exceptions (at DEBUG level) in the server.log when the embedded console is starting up and doing its initial discovery scan, i.e. asking the profile service for a list of stuff which is deployed. I've attached a snippet of the log.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:03:50 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 11:03:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6720) Make sure that the
 metrics for
 Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as
 ViewUse.STATISTIC
In-Reply-To: <7508166.1238615242987.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24766599.1244041433977.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-6720:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> Make sure that the metrics for Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as ViewUse.STATISTIC
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6720
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6720
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: JBoss AS Branch_5_x r86586, embjopr r266
>            Reporter: Farah Juma
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Steps to reproduce:
> Create a new Topic or Queue using Embedded Jopr. Send some messages to the Topic or Queue. Navigate to the "Metrics" tab for the resource. The metrics do not get updated to reflect this change. All the values are 0.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:06:17 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 11:06:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1436) Improved management
Message-ID: <22753413.1244041589934.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-1436:
-------------------------------

    Affects Version/s: JBossAS-5.1.0.GA
           Complexity: Medium
             Priority: Major  (was: Minor)


> Improved management
> -------------------
>
>                 Key: JBAS-1436
>                 URL: https://jira.jboss.org/jira/browse/JBAS-1436
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Adrian Brock
>            Assignee: Vicky Kak
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Forum Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48682
> **This is a holder issue. Each section should be raised as a new issue as it is 
> developed with a link from this issue.**
> There are a number of areas in JCA that need better management capabilities.
> Some of these stats may also reveal the need for new configuration/tuning parameters.
> In core JCA:
> 1) Better visibility on the ManagedConnectionFactory.
> This is currently a DynamicMBean that provides basic config parameters, but we could also
> provide a proxy/wrapper to provide statistics of operations on the factory and its 
> ManagedConnections.
> a) createManagedConnections
> b) matchManagedConnections
> c) events on from the listeners
> 2) Better visibility of the Pool(s)
> Only top level statistics are provided (you cannot see the subpools).
> The statistics are also not synchronized with the pool (for performance reasons
> and also the fact that each stat is retrieved on individual MBean getAttribute requests)
> Additional statistics could include wait times when requests are waiting on an empty pool,
> idle time of unused connections, etc.
> 3) Better visibility of the ConnectionManager
> Currently this has no visibility for management.
> Its main responsibilties are transactions enlistment and security.
> e.g. This could show how long is wasted because <track-connection-by-tx/> does not
> return the connection the pool until transaction completion.
> 4) JDBC resource adapter
> PreparedStatementCache stats
> Query time stats
> etc.
> 5) JMS resource adapter
> Message send/receive stats
> 6) Inbound messaging
> Stats for message delivery
> 7) Transaction inflow
> Stats for transaction inflow and also display a list of current inbound transactions
> 8) Work management
> Stats for the work management pools and timers

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:07:48 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 3 Jun 2009 11:07:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6984) trying to remotely
 retrieve
 statistic properties (e.g. rollbackCount) from MCBean:JTA managed
 components results in "ClassNotFoundException:
 com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
In-Reply-To: <11628190.1243511107980.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24507182.1244041673300.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Charles Crouch updated JBAS-6984:
---------------------------------

    Priority: Critical  (was: Major)


> trying to remotely retrieve statistic properties (e.g. rollbackCount) from MCBean:JTA managed components results in "ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6984
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6984
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>
> 2009-05-28 07:40:01,544 ERROR [ResourceContainer.invoker.daemon-364] (org.rhq.plugins.jbossas5.ApplicationServerComponent)- Failed to obtain metric 'MCBean|JTA|*|rollbackCount'.
> java.lang.IllegalStateException: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:160)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
> 	at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
> 	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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> 	at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1462)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1312)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	... 11 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:09:18 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 3 Jun 2009 11:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1618)
 Connection.close should be synchronous
In-Reply-To: <18244331.1241566547167.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17596129.1244041766729.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil reassigned JBMESSAGING-1618:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Connection.close should be synchronous
> --------------------------------------
>
>                 Key: JBMESSAGING-1618
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1618
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Clebert Suconic
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0 Beta
>
>
> This is related to http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154639
> When connection.close() is called, the server needs some time before releasing the connection.
> There is a FIXME block on ReplicationAwareJMSServerControlWrapperTest::testListRemoteAddresses for this:
>       // FIXME: Closing a connection should be Synchronous
>       //        Remove this loop block when https://jira.jboss.org/jira/browse/JBMESSAGING-1618 is done
>       long timeout = System.currentTimeMillis() + 5000;
>       while (timeout > System.currentTimeMillis() && liveServerControl.listRemoteAddresses().length != 0)
>       {
>          Thread.sleep(10);
>       }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:11:43 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 11:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6999) expose MOs for EJB3
 MDBs w/ some metrics
Message-ID: <23501033.1244041905722.JavaMail.jira@cloud.prod.atl2.jboss.com>

expose MOs for EJB3 MDBs w/ some metrics
----------------------------------------

                 Key: JBAS-6999
                 URL: https://jira.jboss.org/jira/browse/JBAS-6999
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-5.2.0.Beta1


<pilhuhn> Do you also plan to list MDBs so that they can at least be detected?
<ALR> pilhuhn: I hadn't, but I can add that.  What would you like exposed for MDB?
<pilhuhn> metrics like on the jmx console would be cool, but just listing them as ManagedComponent within a EJB jar would be great - they are already in the KnownComponentTypes :)
<ALR> pilhuhn: To list as a ManagedComponent wouldn't I need to register some @ManagementObject ?  Just some stub thing?
<pilhuhn> aehm .. :)
<ALR> pilhuhn: I've found some stats I can expose, actually, without touching the ejb3-core, which has been my aim thus far. :)  I'll do it.
<pilhuhn> Great - JOPR-203 has a EAR attached with a MDB in it - and the jxm-console shows keepalive millis, stats, min pool size, max pool size, delivery active and max messages


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:12:45 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 3 Jun 2009 11:12:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1618)
 Connection.close should be synchronous
In-Reply-To: <18244331.1241566547167.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27657547.1244041978123.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil closed JBMESSAGING-1618.
------------------------------------

    Resolution: Done


fixed in the trunk

> Connection.close should be synchronous
> --------------------------------------
>
>                 Key: JBMESSAGING-1618
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1618
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Clebert Suconic
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0 Beta
>
>
> This is related to http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154639
> When connection.close() is called, the server needs some time before releasing the connection.
> There is a FIXME block on ReplicationAwareJMSServerControlWrapperTest::testListRemoteAddresses for this:
>       // FIXME: Closing a connection should be Synchronous
>       //        Remove this loop block when https://jira.jboss.org/jira/browse/JBMESSAGING-1618 is done
>       long timeout = System.currentTimeMillis() + 5000;
>       while (timeout > System.currentTimeMillis() && liveServerControl.listRemoteAddresses().length != 0)
>       {
>          Thread.sleep(10);
>       }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:15:36 2009
From: jira-events at lists.jboss.org (Travis Scheponik (JIRA))
Date: Wed, 3 Jun 2009 11:15:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2102) Expert evaluate()
 does *not* throw NPE
Message-ID: <5024417.1244042144647.JavaMail.jira@cloud.prod.atl2.jboss.com>

Expert evaluate() does *not* throw NPE
--------------------------------------

                 Key: JBRULES-2102
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2102
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.0.FINAL
         Environment:  java 1.6.0_11, Ubuntu
            Reporter: Travis Scheponik
            Assignee: Mark Proctor


http://pastebin.com/m1dffefc4 <-- offending method within Expert

example ObjectA( a:member1, b:member2, a > b)  <-- this crashes if b is null

example: ObjectA(a:member1, b:member2, eval(a > b )) <-- afaik, this *should* crash  if a or b is null

This was requested to be posted by: etirelli and bjornelo

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:17:10 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 3 Jun 2009 11:17:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6999) expose MOs for
 EJB3 MDBs w/ some metrics
In-Reply-To: <23501033.1244041905722.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16824422.1244042233324.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger commented on JBAS-6999:
-------------------------------------------

Committed in r89742.

> expose MOs for EJB3 MDBs w/ some metrics
> ----------------------------------------
>
>                 Key: JBAS-6999
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6999
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> <pilhuhn> Do you also plan to list MDBs so that they can at least be detected?
> <ALR> pilhuhn: I hadn't, but I can add that.  What would you like exposed for MDB?
> <pilhuhn> metrics like on the jmx console would be cool, but just listing them as ManagedComponent within a EJB jar would be great - they are already in the KnownComponentTypes :)
> <ALR> pilhuhn: To list as a ManagedComponent wouldn't I need to register some @ManagementObject ?  Just some stub thing?
> <pilhuhn> aehm .. :)
> <ALR> pilhuhn: I've found some stats I can expose, actually, without touching the ejb3-core, which has been my aim thus far. :)  I'll do it.
> <pilhuhn> Great - JOPR-203 has a EAR attached with a MDB in it - and the jxm-console shows keepalive millis, stats, min pool size, max pool size, delivery active and max messages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:19:47 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 3 Jun 2009 11:19:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2102) Expert
 evaluate() does *not* throw NPE
In-Reply-To: <5024417.1244042144647.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6715368.1244042393550.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli reassigned JBRULES-2102:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> Expert evaluate() does *not* throw NPE
> --------------------------------------
>
>                 Key: JBRULES-2102
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2102
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.0.FINAL
>         Environment:  java 1.6.0_11, Ubuntu
>            Reporter: Travis Scheponik
>            Assignee: Edson Tirelli
>
> http://pastebin.com/m1dffefc4 <-- offending method within Expert
> example ObjectA( a:member1, b:member2, a > b)  <-- this crashes if b is null
> example: ObjectA(a:member1, b:member2, eval(a > b )) <-- afaik, this *should* crash  if a or b is null
> This was requested to be posted by: etirelli and bjornelo

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:21:25 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 3 Jun 2009 11:21:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6999) expose MOs for
 EJB3 MDBs w/ some metrics
In-Reply-To: <23501033.1244041905722.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28401386.1244042489079.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger commented on JBAS-6999:
-------------------------------------------

Example debug output of an MDB: 

ManagedDeployment: vfszip:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/mdb-test.jar/ +++ ManagedComponent(name=OverrideDefaultedQueueTestMDB-metrics-instance, type=(ComponentType{type=EJB3, subtype=MDB}), compName=OverrideDefaultedQueueTestMDB-metrics-instance, attachment: org.jboss.ejb3.metrics.deployer.BasicMessageDrivenInstanceMetrics ++++++ properties: [maxMessages, deliveryActive, invokeStats, maxPoolSize, keepAliveMillis, minPoolSize] 

> expose MOs for EJB3 MDBs w/ some metrics
> ----------------------------------------
>
>                 Key: JBAS-6999
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6999
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> <pilhuhn> Do you also plan to list MDBs so that they can at least be detected?
> <ALR> pilhuhn: I hadn't, but I can add that.  What would you like exposed for MDB?
> <pilhuhn> metrics like on the jmx console would be cool, but just listing them as ManagedComponent within a EJB jar would be great - they are already in the KnownComponentTypes :)
> <ALR> pilhuhn: To list as a ManagedComponent wouldn't I need to register some @ManagementObject ?  Just some stub thing?
> <pilhuhn> aehm .. :)
> <ALR> pilhuhn: I've found some stats I can expose, actually, without touching the ejb3-core, which has been my aim thus far. :)  I'll do it.
> <pilhuhn> Great - JOPR-203 has a EAR attached with a MDB in it - and the jxm-console shows keepalive millis, stats, min pool size, max pool size, delivery active and max messages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:23:31 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Bj=C3=83=C2=B8rn_Erik_L=C3=83=C2=B8mo_=28JIRA=29?=)
Date: Wed, 3 Jun 2009 11:23:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2102) Expert
 evaluate() does *not* throw NPE
In-Reply-To: <5024417.1244042144647.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3131094.1244042618505.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bj??rn Erik L??mo commented on JBRULES-2102:
--------------------------------------------

In the aforementioned example, if both members are Integer objects, one of them being a nullpointer: If the right hand side of an Integer > Integer comparison is a nullpointer, drools throws a NPE. If the left hand side is null, it works fine. There's a check missing for null values on object2 in this function:

public boolean evaluate(InternalWorkingMemory workingMemory,
                                final InternalReadAccessor extractor1,
                                final Object object1,
                                final InternalReadAccessor extractor2, final Object object2) {
       if( extractor1.isNullValue( workingMemory, object1 ) ) {
                return false;
        }
        return extractor1.getIntValue( workingMemory, object1 ) > extractor2.getIntValue( workingMemory, object2 );
}

Etirelli can probably fill in the rest.

> Expert evaluate() does *not* throw NPE
> --------------------------------------
>
>                 Key: JBRULES-2102
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2102
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.0.FINAL
>         Environment:  java 1.6.0_11, Ubuntu
>            Reporter: Travis Scheponik
>            Assignee: Edson Tirelli
>
> http://pastebin.com/m1dffefc4 <-- offending method within Expert
> example ObjectA( a:member1, b:member2, a > b)  <-- this crashes if b is null
> example: ObjectA(a:member1, b:member2, eval(a > b )) <-- afaik, this *should* crash  if a or b is null
> This was requested to be posted by: etirelli and bjornelo

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Jun  3 11:26:26 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 3 Jun 2009 11:26:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2738166.1244042789759.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry reassigned JBAS-6808:
--------------------------------------

    Assignee: Brian Stansberry  (was: Scott M Stark)


I'll handle this.

> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:29:58 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 3 Jun 2009 11:29:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6877) EJB3 Entity Cache
	Metrics
In-Reply-To: <13995931.1241642506748.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14917937.1244043006729.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry updated JBAS-6877:
-----------------------------------

    Summary: EJB3 Entity Cache Metrics  (was: EJB3 Cache Metrics)


> EJB3 Entity Cache Metrics
> -------------------------
>
>                 Key: JBAS-6877
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6877
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>            Reporter: Andrew Lee Rubinger
>            Assignee: Brian Stansberry
>             Fix For: Backlog
>
>
> These statistics must be reflected in the admin-console/Jopr.
> Split from JBAS-6624:
> EJB3 Entity Tree Cache (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache-->
> <metric property="NumberOfLocksHeld" displayType="summary"/>
>          <metric property="NumberOfNodes" displayType="summary"/>
> EJB3 Entity Tree Cache Interceptor (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache,treecache-interceptor=CacheMgmtInterceptor-->
>             <metric property="HitMissRatio" displayType="summary" units="percentage"
>                     description="Returns the hit/miss ratio for the cache. This ratio is defined as hits/(hits + misses)."/>
>             <metric property="ReadWriteRatio" displayType="summary" units="percentage"
>                     description="Returns the read/write ratio for the cache. This ratio is defined as (hits + misses)/stores."/>
>             <metric property="Hits" displayType="summary"/>
>             <metric property="Misses" displayType="summary"/>
>             <metric property="Evictions" displayType="summary"/>
>             <metric property="NumberOfLocksHeld"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="AverageWriteTime" units="milliseconds"/>
>             <metric property="TimeSinceReset" units="seconds"/>
>             <metric property="AverageReadTime" units="milliseconds"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="Stores"/>
>             <metric property="NumberOfAttributes"/>
>             <metric property="ElapsedTime" units="milliseconds"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 12:28:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 3 Jun 2009 12:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2102) Expert evaluate()
 does *not* throw NPE
In-Reply-To: <5024417.1244042144647.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33500717.1244046536567.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli closed JBRULES-2102.
----------------------------------

    Fix Version/s: 5.1.0.M1
       Resolution: Done


Fixed. Thanks for reporting.

> Expert evaluate() does *not* throw NPE
> --------------------------------------
>
>                 Key: JBRULES-2102
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2102
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.0.FINAL
>         Environment:  java 1.6.0_11, Ubuntu
>            Reporter: Travis Scheponik
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> http://pastebin.com/m1dffefc4 <-- offending method within Expert
> example ObjectA( a:member1, b:member2, a > b)  <-- this crashes if b is null
> example: ObjectA(a:member1, b:member2, eval(a > b )) <-- afaik, this *should* crash  if a or b is null
> This was requested to be posted by: etirelli and bjornelo

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 13:07:14 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 3 Jun 2009 13:07:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBWEB-140) Define javac target
 for build consistency
Message-ID: <3295821.1244048854856.JavaMail.jira@cloud.prod.atl2.jboss.com>

Define javac target for build consistency
-----------------------------------------

                 Key: JBWEB-140
                 URL: https://jira.jboss.org/jira/browse/JBWEB-140
             Project: JBoss Web
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Core
    Affects Versions: JBossWeb-2.0.0.GA_CP09
            Reporter: Mike Millson
            Assignee: Mike Millson


Currently the build will target the JVM version being used to run the ant build task. Add the ability to build with JDK 1.6 by specifying the javac target to 1.5.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 13:08:57 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 3 Jun 2009 13:08:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-140) Define javac target
 for build consistency
In-Reply-To: <3295821.1244048854856.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29577220.1244048938158.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-140:
-------------------------------

    Attachment: build.xml.patch


Proposed patch. 

ant.build.javac.target is also defined because it has been observed that the javac target is ignored with ant 1.7 and FC10 x86-64 OpenJDK 64-Bit. With ant 1.7, the javac default target is ant.build.javac.target, so this is a workaround for those cases.

> Define javac target for build consistency
> -----------------------------------------
>
>                 Key: JBWEB-140
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-140
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Mike Millson
>         Attachments: build.xml.patch
>
>
> Currently the build will target the JVM version being used to run the ant build task. Add the ability to build with JDK 1.6 by specifying the javac target to 1.5.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 13:13:25 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 3 Jun 2009 13:13:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1558)
 @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) ignored on
 MDB onMessage
In-Reply-To: <6182654.1225298240959.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22292528.1244049205080.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf updated EJBTHREE-1558:
------------------------------------

      Component/s: core
    Fix Version/s: 1.1.7


> @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) ignored on MDB onMessage
> --------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1558
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1558
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: AS 4.2.2.GA
>            Reporter: Justin Bertram
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.7
>
>
> Even when putting:
>   @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
> on the onMessage method of an MDB a transaction is still started.  This can be verified by using a simple MDB that sleeps for longer than the transaction timeout (300 seconds by default).  For example:
>   import javax.ejb.ActivationConfigProperty;
>   import javax.ejb.MessageDriven;
>   import javax.ejb.TransactionAttribute;
>   import javax.ejb.TransactionAttributeType;
>   import javax.jms.Message;
>   import javax.jms.MessageListener;
>   
>   import org.apache.log4j.Logger;
>   
>   @MessageDriven(activationConfig = { 
>   		@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), 
>   		@ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/A"), 
>   		@ActivationConfigProperty(propertyName = "maxSession", propertyValue = "3") })
>   public class ExampleEJB3MDB implements MessageListener {
>   	private static final Logger logger = Logger.getLogger(ExampleEJB3MDB.class);
>   
>   	@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
>   	public void onMessage(Message m) {
>   		logger.info("message received, waiting for 10 mins...");
>   
>   		try {
>   			Thread.sleep(600000); // 10 mins
>   
>   		} catch (InterruptedException e) {
>   		}
>   
>   		logger.info("finished waiting");
>   	}
>   }
> When a message is sent to "queue/A" and the MDB picks it up it prints "message received, waiting for 10 mins..." in the log.  After 5 minutes (300 seconds) the message appears in the log again because the transaction has timed-out and the message has been redelivered.
> I believe the problem lies in org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory in the isDeliveryTransacted method.  Here is that method [1]:
>   public boolean isDeliveryTransacted(Method method) throws NoSuchMethodException
>      {
>         TransactionManagementType mtype = TxUtil.getTransactionManagementType(container);
>         if (mtype == javax.ejb.TransactionManagementType.BEAN) return false;
>   
>   
>         TransactionAttribute attr = (TransactionAttribute)container.resolveAnnotation(method, TransactionAttribute.class);
>         if (attr == null)
>         {
>            attr =(TransactionAttribute)container.resolveAnnotation(TransactionAttribute.class);
>         }
>         TransactionAttributeType type = TransactionAttributeType.REQUIRED;
>         if (attr != null) type = attr.value();
>         return type == javax.ejb.TransactionAttributeType.REQUIRED;
>      }
> It seems there should be an explicit check for TransactionAttributeType.NOT_SUPPORTED.  If the MDB uses @TransactionManagement(TransactionManagementType.BEAN) then the redelivery doesn't occur (since the code explicitly checks this attribute and returns false if it is present).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 13:13:25 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 3 Jun 2009 13:13:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1558)
 @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) ignored on
 MDB onMessage
In-Reply-To: <6182654.1225298240959.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26483680.1244049205255.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf resolved EJBTHREE-1558.
-------------------------------------

    Resolution: Done


> @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) ignored on MDB onMessage
> --------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1558
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1558
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: AS 4.2.2.GA
>            Reporter: Justin Bertram
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.7
>
>
> Even when putting:
>   @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
> on the onMessage method of an MDB a transaction is still started.  This can be verified by using a simple MDB that sleeps for longer than the transaction timeout (300 seconds by default).  For example:
>   import javax.ejb.ActivationConfigProperty;
>   import javax.ejb.MessageDriven;
>   import javax.ejb.TransactionAttribute;
>   import javax.ejb.TransactionAttributeType;
>   import javax.jms.Message;
>   import javax.jms.MessageListener;
>   
>   import org.apache.log4j.Logger;
>   
>   @MessageDriven(activationConfig = { 
>   		@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), 
>   		@ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/A"), 
>   		@ActivationConfigProperty(propertyName = "maxSession", propertyValue = "3") })
>   public class ExampleEJB3MDB implements MessageListener {
>   	private static final Logger logger = Logger.getLogger(ExampleEJB3MDB.class);
>   
>   	@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
>   	public void onMessage(Message m) {
>   		logger.info("message received, waiting for 10 mins...");
>   
>   		try {
>   			Thread.sleep(600000); // 10 mins
>   
>   		} catch (InterruptedException e) {
>   		}
>   
>   		logger.info("finished waiting");
>   	}
>   }
> When a message is sent to "queue/A" and the MDB picks it up it prints "message received, waiting for 10 mins..." in the log.  After 5 minutes (300 seconds) the message appears in the log again because the transaction has timed-out and the message has been redelivered.
> I believe the problem lies in org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory in the isDeliveryTransacted method.  Here is that method [1]:
>   public boolean isDeliveryTransacted(Method method) throws NoSuchMethodException
>      {
>         TransactionManagementType mtype = TxUtil.getTransactionManagementType(container);
>         if (mtype == javax.ejb.TransactionManagementType.BEAN) return false;
>   
>   
>         TransactionAttribute attr = (TransactionAttribute)container.resolveAnnotation(method, TransactionAttribute.class);
>         if (attr == null)
>         {
>            attr =(TransactionAttribute)container.resolveAnnotation(TransactionAttribute.class);
>         }
>         TransactionAttributeType type = TransactionAttributeType.REQUIRED;
>         if (attr != null) type = attr.value();
>         return type == javax.ejb.TransactionAttributeType.REQUIRED;
>      }
> It seems there should be an explicit check for TransactionAttributeType.NOT_SUPPORTED.  If the MDB uses @TransactionManagement(TransactionManagementType.BEAN) then the redelivery doesn't occur (since the code explicitly checks this attribute and returns false if it is present).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 13:28:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 3 Jun 2009 13:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1843) All SFSB Cache
 implementations return -1 for getAvailableCount
Message-ID: <30033959.1244050136541.JavaMail.jira@cloud.prod.atl2.jboss.com>

All SFSB Cache implementations return -1 for getAvailableCount
--------------------------------------------------------------

                 Key: EJBTHREE-1843
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1843
             Project: EJB 3.0
          Issue Type: Bug
          Components: core
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.1.7, EAP 5


SFSB Metrics getAvailableCount, powered by inquiring upon the caches, always return -1.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 13:30:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 3 Jun 2009 13:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1843) All SFSB Cache
 implementations return -1 for getAvailableCount
In-Reply-To: <30033959.1244050136541.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8204388.1244050256762.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger resolved EJBTHREE-1843.
-------------------------------------------

    Resolution: Done


> All SFSB Cache implementations return -1 for getAvailableCount
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-1843
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1843
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.7, EAP 5
>
>
> SFSB Metrics getAvailableCount, powered by inquiring upon the caches, always return -1.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 14:34:07 2009
From: jira-events at lists.jboss.org (Mattias Neuling (JIRA))
Date: Wed, 3 Jun 2009 14:34:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSER-115) Exception while
 deserialization
 of java.math.BigInteger in Sun JRE 1.6.0_14 if serialized using a previous
 version e.g. JRE 1.6.0_13.
Message-ID: <21017092.1244054047588.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exception while deserialization of java.math.BigInteger in Sun JRE 1.6.0_14 if serialized using a previous version e.g. JRE 1.6.0_13. 
--------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBSER-115
                 URL: https://jira.jboss.org/jira/browse/JBSER-115
             Project: JBoss Serialization
          Issue Type: Bug
    Affects Versions: 1.0.3 GA
         Environment: Deserializing client:
- OS: Windows XP SP3 (32Bit)
- JRE 1.6.0_14

Serializing Server:
- OS: Linux Suse Enterprise (64 Bit)
- JDK 1.6.0_13 (64 Bit)
            Reporter: Mattias Neuling
            Assignee: Clebert Suconic


Failure while deserilizing java.math.BigInteger in java.math.BigDecimal on client side:
Stacktrace:
 java.io.IOException: Current classpath has lesser fields on java.math.BigInteger than its original version
	at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:98)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:381)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
	at org.jboss.serial.persister.ObjectInputStreamProxy.defaultReadObject(ObjectInputStreamProxy.java:78)
	at java.math.BigDecimal.readObject(Unknown Source)
	... 42 more


In JDK 1.6.0_14 java.math.BigInteger has one field more than in previous versions. Serialization without JBoss Serialization is no problem since it implements the methods #readObject() and #writeObject().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 15:05:57 2009
From: jira-events at lists.jboss.org (Guillaume Jeudy (JIRA))
Date: Wed, 3 Jun 2009 15:05:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1374) DLQ
 override depends on the queues definition order.
In-Reply-To: <24976851.1213606723479.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29433851.1244055957072.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Guillaume Jeudy commented on JBMESSAGING-1374:
----------------------------------------------

Is that fix supposed to work with a durable subscription? I have a durable subscriber MDB to the topic defined below (in the correct order).  It seems as though the DLQ configuration is completely ignored and the messages are routed to the default DLQ. I'm using jboss messaging 1.4.4.GA.

<mbean code="org.jboss.jms.server.destination.QueueService"
      name="jboss.messaging.destination:service=Queue,name=msdmiTopicDLQ"
      xmbean-dd="xmdesc/Queue-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
      <attribute name="JNDIName">BOSS/DLQ/AuditServices/Events/Sharepoint</attribute>
   </mbean>   

   <mbean code="org.jboss.jms.server.destination.TopicService"
      name="jboss.messaging.destination:service=Topic,name=msdmiTopic"
      xmbean-dd="xmdesc/Topic-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
      <attribute name="JNDIName">BOSS/AuditServices/Events/Sharepoint</attribute>
      <attribute name="DLQ">jboss.messaging.destination:service=Queue,name=msdmiTopicDLQ</attribute>
   </mbean>

> DLQ override depends on the queues definition order.
> ----------------------------------------------------
>
>                 Key: JBMESSAGING-1374
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1374
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Howard Gao
>             Fix For:  1.4.0.SP3.CP04, 1.4.1.GA, 1.4.2.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 15:37:56 2009
From: jira-events at lists.jboss.org (Guillaume Jeudy (JIRA))
Date: Wed, 3 Jun 2009 15:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1374) DLQ
 override depends on the queues definition order.
In-Reply-To: <24976851.1213606723479.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9851196.1244057876835.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Guillaume Jeudy commented on JBMESSAGING-1374:
----------------------------------------------

I stumbled upon this case: https://64.74.196.157/jira/browse/JBPAPP-871. Apparently my MDB had DLQMaxSent set to 2 so the MDB DLQ policy took precedence over JBM DLQ policy...

> DLQ override depends on the queues definition order.
> ----------------------------------------------------
>
>                 Key: JBMESSAGING-1374
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1374
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Howard Gao
>             Fix For:  1.4.0.SP3.CP04, 1.4.1.GA, 1.4.2.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 16:09:56 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Wed, 3 Jun 2009 16:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-84) WS-Trust: SAML Token
	Profile
In-Reply-To: <22333787.1240932058813.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7844228.1244059796996.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Stefan Guilhen closed JBID-84.
------------------------------

    Resolution: Done


The JBossSTS now has a SAML20TokenProvider that handles WS-Trust SAML requests.

> WS-Trust: SAML Token Profile
> ----------------------------
>
>                 Key: JBID-84
>                 URL: https://jira.jboss.org/jira/browse/JBID-84
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha2
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.beta1
>
>
> SOA-692 has requirements.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 16:09:56 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Wed, 3 Jun 2009 16:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-124) Implement WS-T SAML
 Token Profile:: SAMLV2.0 validation
In-Reply-To: <26312958.1243987260389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9839429.1244059796790.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Stefan Guilhen closed JBID-124.
-------------------------------

    Resolution: Done


SAMLV2.0 assertion validation has been implemented in the SAML20TokenProvider class.

> Implement WS-T SAML Token Profile:: SAMLV2.0 validation
> -------------------------------------------------------
>
>                 Key: JBID-124
>                 URL: https://jira.jboss.org/jira/browse/JBID-124
>             Project: JBoss Identity
>          Issue Type: Sub-task
>          Components: Identity-Federation
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha3
>
>
> The SAML token provider must be able to validate the assertions it generates. This involves validating the digital signature and also the assertion validity period (lifetime).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 17:36:56 2009
From: jira-events at lists.jboss.org (Graham Gear (JIRA))
Date: Wed, 3 Jun 2009 17:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2103)
 Knowledge*/ChangeSet APIs to
 be extended to support BRL, DSLR and DroolsCompilerAntTask compiled rules
Message-ID: <25039788.1244065016626.JavaMail.jira@cloud.prod.atl2.jboss.com>

Knowledge*/ChangeSet APIs to be extended to support BRL, DSLR and DroolsCompilerAntTask compiled rules
------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2103
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2103
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-api, drools-compiler, drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Graham Gear
            Assignee: Mark Proctor


I would like to see the new Knowledge*/ChangeSet API's to be extended to support all rule types, including BRL, DSLR and DroolsCompilerAntTask compiled rules

Although the primary compilation mechanism for BRL and DSLR  types of rules will likely be Guvnor, for completeness and an aid for developer driven rules, debug and automation I would like to see the API filled out.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 17:48:56 2009
From: jira-events at lists.jboss.org (Graham Gear (JIRA))
Date: Wed, 3 Jun 2009 17:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2104)
 KnowledgeAgentImpl cannot
 build Resources with paramatereised ResourceConfiguration's
Message-ID: <2223936.1244065736508.JavaMail.jira@cloud.prod.atl2.jboss.com>

KnowledgeAgentImpl cannot build Resources with paramatereised ResourceConfiguration's
-------------------------------------------------------------------------------------

                 Key: JBRULES-2104
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2104
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Graham Gear
            Assignee: Mark Proctor


The KnowledgeAgentImpl does not pass through ResourceConfiguration's through to KnowledgeBuilderImpl, making the building of configuration parametrised Resources not possible. Eg, trying to compile a DecisionTable (XLS) results in a NPE:

Caused by: java.lang.NullPointerException
	at org.drools.decisiontable.DecisionTableProviderImpl.compileStream(DecisionTableProviderImpl.java:26)
	at org.drools.decisiontable.DecisionTableProviderImpl.loadFromInputStream(DecisionTableProviderImpl.java:19)
	at org.drools.compiler.DecisionTableFactory.loadFromInputStream(DecisionTableFactory.java:16)
	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:508)
	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:25)
	at org.drools.agent.impl.KnowledgeAgentImpl.rebuildResources(KnowledgeAgentImpl.java:385)
	at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:119)
	at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:108)
	at com.jboss.brms.poc.KnowledgeBaseManager.loadChangeSet(KnowledgeBaseManager.java:78)
	at com.jboss.brms.poc.test.rule.DecisionTableBRLClassPathRuleTest.<clinit>(DecisionTableBRLClassPathRuleTest.java:18)
	... 17 more

In general it would be good if the KnowledgeAgent would behave exactly as the KnowledgeBuilder under the same ChangeSet configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 17:48:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 3 Jun 2009 17:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2105) For literal
 constraints on
 BitDecimal and BigIntegers, avoid coercing the literal every constraint
 check
Message-ID: <612131.1244065736734.JavaMail.jira@cloud.prod.atl2.jboss.com>

For literal constraints on BitDecimal and BigIntegers, avoid coercing the literal every constraint check
--------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2105
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2105
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


Cache it instead.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 17:50:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 3 Jun 2009 17:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2105) For literal
 constraints on
 BitDecimal and BigIntegers, avoid coercing the literal every constraint
 check
In-Reply-To: <612131.1244065736734.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20832912.1244065856720.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli closed JBRULES-2105.
----------------------------------

    Resolution: Done


Fixed. Thanks for reporting.

> For literal constraints on BitDecimal and BigIntegers, avoid coercing the literal every constraint check
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2105
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2105
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> Cache it instead.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 17:50:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 3 Jun 2009 17:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2105) For literal
 constraints on
 BitDecimal and BigIntegers, avoid coercing the literal every constraint
 check
In-Reply-To: <612131.1244065736734.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4222879.1244065856843.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli commented on JBRULES-2105:
----------------------------------------

committed to revision #26819 in trunk.

> For literal constraints on BitDecimal and BigIntegers, avoid coercing the literal every constraint check
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2105
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2105
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> Cache it instead.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 18:22:56 2009
From: jira-events at lists.jboss.org (wallace njoroge (JIRA))
Date: Wed, 3 Jun 2009 18:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7000) issues when starting
 jboss server using Linux centos 5.3
Message-ID: <6401897.1244067776524.JavaMail.jira@cloud.prod.atl2.jboss.com>

issues when starting jboss server using Linux centos 5.3
--------------------------------------------------------

                 Key: JBAS-7000
                 URL: https://jira.jboss.org/jira/browse/JBAS-7000
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMX/Web Console
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: wallace njoroge
            Assignee: Darran Lofthouse


Environment:

Centos 5.3  running in VM
Linux  2.6.18-128.1.10.el5 #1 i686 i686 i386 GNU/Linux

java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)


Steps.
1. $ pwd
/usr/local/jboss/bin

2. run.sh 



pdadmin at PDPERFAppLnx01 bin]$ ./run.sh
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /usr/local/jboss
  JAVA: /home/centosadmin/jdk1.6.0_13/bin/java

  JAVA_OPTS: -Dprogram.name=run.sh -server -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true

  CLASSPATH: /usr/local/jboss/bin/run.jar:/home/centosadmin/jdk1.6.0_13/lib/tools.jar

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

15:14:42,090 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
15:14:42,091 INFO  [ServerImpl] Release ID: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)
15:14:42,092 INFO  [ServerImpl] Bootstrap URL: null
15:14:42,092 INFO  [ServerImpl] Home Dir: /usr/local/jboss
15:14:42,092 INFO  [ServerImpl] Home URL: file:/usr/local/jboss/
15:14:42,092 INFO  [ServerImpl] Library URL: file:/usr/local/jboss/lib/
15:14:42,093 INFO  [ServerImpl] Patch URL: null
15:14:42,093 INFO  [ServerImpl] Common Base URL: file:/usr/local/jboss/common/
15:14:42,094 INFO  [ServerImpl] Common Library URL: file:/usr/local/jboss/common/lib/
15:14:42,094 INFO  [ServerImpl] Server Name: default
15:14:42,094 INFO  [ServerImpl] Server Base Dir: /usr/local/jboss/server
15:14:42,094 INFO  [ServerImpl] Server Base URL: file:/usr/local/jboss/server/
15:14:42,095 INFO  [ServerImpl] Server Config URL: file:/usr/local/jboss/server/default/conf/
15:14:42,095 INFO  [ServerImpl] Server Home Dir: /usr/local/jboss/server/default
15:14:42,095 INFO  [ServerImpl] Server Home URL: file:/usr/local/jboss/server/default/
15:14:42,095 INFO  [ServerImpl] Server Data Dir: /usr/local/jboss/server/default/data
15:14:42,096 INFO  [ServerImpl] Server Library URL: file:/usr/local/jboss/server/default/lib/
15:14:42,096 INFO  [ServerImpl] Server Log Dir: /usr/local/jboss/server/default/log
15:14:42,096 INFO  [ServerImpl] Server Native Dir: /usr/local/jboss/server/default/tmp/native
15:14:42,096 INFO  [ServerImpl] Server Temp Dir: /usr/local/jboss/server/default/tmp
15:14:42,097 INFO  [ServerImpl] Server Temp Deploy Dir: /usr/local/jboss/server/default/tmp/deploy
15:14:42,975 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/usr/local/jboss/server/default/conf/bootstrap.xml
15:14:43,586 INFO  [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.plugins.cache.CombinedVFSCache]
15:14:43,589 INFO  [VFSCacheFactory] Using VFSCache [CombinedVFSCache[real-cache: null]]
15:14:43,940 INFO  [CopyMechanism] VFS temp dir: /usr/local/jboss/server/default/tmp
15:14:43,941 INFO  [ZipEntryContext] VFS force nested jars copy-mode is enabled.
15:14:45,822 INFO  [ServerInfo] Java version: 1.6.0_13,Sun Microsystems Inc.
15:14:45,822 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
15:14:45,823 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Server VM 11.3-b02,Sun Microsystems Inc.
15:14:45,823 INFO  [ServerInfo] OS-System: Linux 2.6.18-128.1.10.el5,i386
15:14:45,824 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/usr/local/jboss/lib/endorsed
15:14:45,905 INFO  [JMXKernel] Legacy JMX core initialized
15:14:49,308 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 487fb7[domain=default, server=default, name=default]
15:14:50,731 ERROR [AbstractKernelController] Error installing to Parse: name=vfsfile:/usr/local/jboss/server/default/conf/jboss-service.xml state=Not Installed mode=Manual requiredState=Parse
org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfsfile:/usr/local/jboss/server/default/conf/jboss-service.xml
        at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
        at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:362)
        at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:322)
        at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:294)
        at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.deploy(AbstractParsingDeployerWithOutput.java:234)
        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.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.jbos



Expected.
Should work


Error:
Error creating managed object for vfsfile:/usr/local/jboss/server/default/conf/jboss-service.xml

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 19:29:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 3 Jun 2009 19:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2106) Allow "implicit"
 operators in the language
Message-ID: <13932462.1244071796460.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow "implicit" operators in the language
------------------------------------------

                 Key: JBRULES-2106
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2106
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


It would be cool if we could develop and enable "implicit" operators. By that I mean, a method that returns a boolean and take 1 parameter could be used automatically. Example:

Person( name startsWith "Edson" )

The engine would understand the "startsWith" implicit operator, and would call the method on the name String.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 19:42:09 2009
From: jira-events at lists.jboss.org (Mauricio Salatino (JIRA))
Date: Wed, 3 Jun 2009 19:42:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2107) Support StateNode
 for Finite State Machines
Message-ID: <19207617.1244072529147.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support StateNode for Finite State Machines
-------------------------------------------

                 Key: JBRULES-2107
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2107
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler (flow), drools-core (flow)
    Affects Versions: 5.1.0.M1
            Reporter: Mauricio Salatino
            Assignee: Mauricio Salatino


Support for StateNode for Finite State Machines

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 22:13:56 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 3 Jun 2009 22:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-288) Errors show up in
	problems view
In-Reply-To: <13325945.1231384923985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29218660.1244081636386.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Koen Aers updated GPD-288:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.GA
                       (was: jBPM jPDL Designer 4.0.0.CR1)


some work still needs to be done, slip to GA release

> Errors show up in problems view
> -------------------------------
>
>                 Key: GPD-288
>                 URL: https://jira.jboss.org/jira/browse/GPD-288
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>            Priority: Critical
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Process errors (e.g. duplicate node names) should show up in the problems view and should have the 'problem' annotation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 22:16:08 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 3 Jun 2009 22:16:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-331) Support HQL attributes
	and elements
In-Reply-To: <143992.1241701546509.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20229445.1244081768273.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Koen Aers updated GPD-331:
--------------------------


slip to GA release

> Support HQL attributes and elements
> -----------------------------------
>
>                 Key: GPD-331
>                 URL: https://jira.jboss.org/jira/browse/GPD-331
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> attributes: var, unique
> elements: query, parameter

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 22:16:08 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 3 Jun 2009 22:16:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-331) Support HQL attributes
	and elements
In-Reply-To: <143992.1241701546509.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23790358.1244081768383.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Koen Aers updated GPD-331:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.GA
                       (was: jBPM jPDL Designer 4.0.0.CR1)


> Support HQL attributes and elements
> -----------------------------------
>
>                 Key: GPD-331
>                 URL: https://jira.jboss.org/jira/browse/GPD-331
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> attributes: var, unique
> elements: query, parameter

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 22:16:08 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 3 Jun 2009 22:16:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-335) add proper licence
	text
In-Reply-To: <6494146.1242893636570.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4025578.1244081768172.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Koen Aers resolved GPD-335.
---------------------------

    Resolution: Done


EPL license is contained in all the features

> add proper licence text
> -----------------------
>
>                 Key: GPD-335
>                 URL: https://jira.jboss.org/jira/browse/GPD-335
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.CR1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 22:17:56 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 3 Jun 2009 22:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-341) renaming swimlane
 should make editor dirty
In-Reply-To: <31349923.1243352997231.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23216847.1244081876375.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Koen Aers updated GPD-341:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.GA
                       (was: jBPM jPDL Designer 4.0.0.CR1)


slip to GA release

> renaming swimlane should make editor dirty
> ------------------------------------------
>
>                 Key: GPD-341
>                 URL: https://jira.jboss.org/jira/browse/GPD-341
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 23:12:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 3 Jun 2009 23:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-126) IDPWebBrowserSSOValve
 needs work to send the error response properly
Message-ID: <4282669.1244085176426.JavaMail.jira@cloud.prod.atl2.jboss.com>

IDPWebBrowserSSOValve needs work to send the error response properly 
---------------------------------------------------------------------

                 Key: JBID-126
                 URL: https://jira.jboss.org/jira/browse/JBID-126
             Project: JBoss Identity
          Issue Type: Bug
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


When there are exceptions such as IssuerNoTrustedException, the IDP should send a proper saml response.  For this, the valve needs to preprocess the saml request and determine the assertion consumer url.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 00:14:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 4 Jun 2009 00:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-198) Default namespace
	for connector
In-Reply-To: <31227187.1242149206811.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3254849.1244088896621.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Zhang resolved JBMETA-198.
-------------------------------

    Fix Version/s: 1.0.2.Beta1
       Resolution: Done


> Default namespace for connector
> -------------------------------
>
>                 Key: JBMETA-198
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-198
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Zhang
>             Fix For: 1.0.2.Beta1
>
>
> If the user doesn't specify a namespace in the ra.xml - like
>  <connector>
> and there isn't a DTD definition either we should map that namespace to JCA15MetaData.
> That would allow the RA deployer to continue to parse the file and log a WARN to the user.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 00:17:08 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 4 Jun 2009 00:17:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-199) Default namespace
	for jboss-ra
In-Reply-To: <1877135.1242149339350.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27831789.1244089028420.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Zhang resolved JBMETA-199.
-------------------------------

    Fix Version/s: 1.0.2.Beta1
       Resolution: Done


> Default namespace for jboss-ra
> ------------------------------
>
>                 Key: JBMETA-199
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-199
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Zhang
>             Fix For: 1.0.2.Beta1
>
>
> If the user doesn't specify a namespace in the jboss-ra.xml - like
>  <jboss-ra>
> and there isn't a DTD definition either we should map that namespace to JBossRAMetaData.
> That would allow the RA deployer to continue to parse the file and log a WARN to the user.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 01:37:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 4 Jun 2009 01:37:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1637) Interruption
	is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24447070.1244093878006.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao updated JBMESSAGING-1637:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09


> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 01:41:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 4 Jun 2009 01:41:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1637)
	Interruption is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12074069.1244094117230.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1637:
-----------------------------------------

Hi David, Thanks for explanation.


> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 03:32:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 4 Jun 2009 03:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-947) Messages that are
 bundled but
 are over max_bundle_size are silently dropped on the floor.
In-Reply-To: <7003516.1238675182543.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17198625.1244100776703.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban commented on JGRP-947:
-------------------------------

NAKACK actually doesn't use OOB anymore, so retransmitted messages *are* bundled. This means that every retransmission causes this stack trace.

Propagating the exception all the way up to the caller is not a good idea IMO, because the caller might re-send the buffer and then we even compound the issue.

I guess we need to catch this misconfiguration issue at stack start time, ie. throw an exception if FRAG2.frag_size > TP.max_bundle_size (if bundling is enabled)

> Messages that are bundled but are over max_bundle_size are silently dropped on the floor.
> -----------------------------------------------------------------------------------------
>
>                 Key: JGRP-947
>                 URL: https://jira.jboss.org/jira/browse/JGRP-947
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: JGroups version 2.7.0
>            Reporter: Hunter Kelly
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> in TP.java, at line 1562, an error is thrown if a packet is too big.  However, this exception is caught in TP.java at line 913.  It is logged, but in my opinion this error should be propagated all the way up the call stack.
> This causes particularly confusing behavior when NACKACK is in the stack, because the next time a message that is sent that is small enough, any and all receivers will ask for a re-transmit of this message from the sender, and the default code path will then _not_ go through the bundler, so the packet will then be successfully sent.
> This means that you get a dire looking log message but code that still works, but (potentially) much more inefficiantly.
> IMHO, errors like this should be propagated back up to the offending code, so that the error can be detected and corrected.
> It also makes it virtually impossible to write test code that tests behaviour of different JGroups configurations.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 03:39:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 4 Jun 2009 03:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-947) Messages that are
 bundled but are
 over max_bundle_size are silently dropped on the floor.
In-Reply-To: <7003516.1238675182543.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5736080.1244101196704.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban resolved JGRP-947.
---------------------------

    Resolution: Done


I added a check to FRAG2 which makes sure frag_size < TP.max_bundle_size (if bundling is enabled)

> Messages that are bundled but are over max_bundle_size are silently dropped on the floor.
> -----------------------------------------------------------------------------------------
>
>                 Key: JGRP-947
>                 URL: https://jira.jboss.org/jira/browse/JGRP-947
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: JGroups version 2.7.0
>            Reporter: Hunter Kelly
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> in TP.java, at line 1562, an error is thrown if a packet is too big.  However, this exception is caught in TP.java at line 913.  It is logged, but in my opinion this error should be propagated all the way up the call stack.
> This causes particularly confusing behavior when NACKACK is in the stack, because the next time a message that is sent that is small enough, any and all receivers will ask for a re-transmit of this message from the sender, and the default code path will then _not_ go through the bundler, so the packet will then be successfully sent.
> This means that you get a dire looking log message but code that still works, but (potentially) much more inefficiantly.
> IMHO, errors like this should be propagated back up to the offending code, so that the error can be detected and corrected.
> It also makes it virtually impossible to write test code that tests behaviour of different JGroups configurations.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 03:56:09 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 4 Jun 2009 03:56:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-967) Deadlock in FD_SOCK
In-Reply-To: <31434384.1240948306486.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8212586.1244102170427.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban updated JGRP-967:
--------------------------

    Fix Version/s: 2.4.7
                       (was: 2.8)


Moved to 2.4.7

> Deadlock in FD_SOCK 
> --------------------
>
>                 Key: JGRP-967
>                 URL: https://jira.jboss.org/jira/browse/JGRP-967
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.5
>         Environment: Deadlock detected on Fedora 8, JDK 1.4/JDK 1.5.
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.4.7
>
>         Attachments: example0.png, example1.png, threadDump.FD_SOCK.txt
>
>
> Due to a problem with IPv6 addresses and ServerSocket connections hanging, a deadlock was revealed in FD_SOCK. 
> The deadlock reveals itself, for example, in the test RpcDispatcherAnycastTest at the end of the test, when the channels are being torn down. What follows are my original emails to Bela:
> Richard: 
> I've tracked down the test case failure of RpcDispatcherAnycastTest under IPv6 to a problem with shutting down the protocol stack. The test executes fine, but in the teardown phase, when the test tries to close the three JChannels which have been set up, the first channel closes correctly, but the second channel hangs.
> JChannel tries to disconnect from the group before shutting down by:
> (i) sending a DISCONNECT event and waits for a DISCONNECT_OK event via a promise
> (ii) sending a STOP_QUEUING event and waita for a return from the call (i.e. has reached the bottom of the stack)
> It then calls ProtocolStack.stopStack() which sends a STOP event down the stack and waits for a STOP_OK event via a promise.
> The STOP event is not making its way correctly down the stack.
> Here is a trace with IPv4 (i've added in some tracing of the STOP event of my own):
>    [junit] JChannel.disconnect(): waiting for DISCONNECT_OK
>    [junit] JChannel.disconnect(): got DISCONNECT_OK
>    [junit] JChannel.disconnect(): stopping queue
>    [junit] FD_SOCK.down called, event = STOP_QUEUEING
>    [junit] JChannel.disconnect(): stopped queue
>    [junit] JChannel.disconnect(): stopping stack
>    [junit] ProtocolStack: Sending STOP event
>    [junit] STATE_TRANSFER: STOP event received
>    [junit] FRAG2: STOP event received
>    [junit] FC: STOP event received
>    [junit] GMS: STOP event received
>    [junit] VIEW_SYNC: STOP event received
>    [junit] pbcast.STABLE: STOP event received
>    [junit] UNICAST: STOP event received
>    [junit] VERIFY_SUSPECT: STOP event received
>    [junit] FD: STOP event received
>    [junit] FD_SOCK.down called, event = STOP
>    [junit] FD_SOCK: STOP event received
>    [junit] MERGE2: STOP event received
>    [junit] PING: STOP event received
>    [junit] ProtocolStack: Received STOP event
>    [junit] JChannel.disconnect(): stopped stack
> Here is a bad trace with IPv6:
>    [junit] JChannel.disconnect(): waiting for DISCONNECT_OK
>    [junit] JChannel.disconnect(): got DISCONNECT_OK
>    [junit] JChannel.disconnect(): stopping queue
>    [junit] FD_SOCK.down called, event = STOP_QUEUEING
>    [junit] JChannel.disconnect(): stopped queue
>    [junit] JChannel.disconnect(): stopping stack
>    [junit] ProtocolStack: Sending STOP event
>    [junit] STATE_TRANSFER: STOP event received
>    [junit] FRAG2: STOP event received
>    [junit] FC: STOP event received
>    [junit] GMS: STOP event received
>    [junit] VIEW_SYNC: STOP event received
>    [junit] pbcast.STABLE: STOP event received
>    [junit] UNICAST: STOP event received
>    [junit] VERIFY_SUSPECT: STOP event received
>    [junit] FD: STOP event received
>    [junit] FD_SOCK.down called, event = MSG
>    [junit] FD_SOCK.down called, event = MSG
>    [junit] FD_SOCK.down called, event = MSG
>    [junit] FD_SOCK.down called, event = MSG
> If I remove FD_SOCK from the stack, the tests pass. If I include it, this stuff happens.
> I also found that if I turn on the uphandler and downhandler threads in FD_SOCK, the problem disappears:
> ...
>    <MERGE2 max_interval="30000" down_thread="false" up_thread="false" min_interval="10000"/>
>    <FD_SOCK down_thread="true" up_thread="true"/>    <FD timeout="10000" max_tries="5" down_thread="false" up_thread="false" shun="true"/>
> ...
> Bela:
> Then it must be a locking issue, I'll take a look tomorrow. Or if you find the solution sooner, all the better !  :-)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 03:59:41 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 4 Jun 2009 03:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6981) AttachmentStore MC
 bean
 (org.jboss.system.server.profileservice.repository.AbstractAttachmentStore)
 configuration does not specify the parameter type for constructor
In-Reply-To: <13505017.1243427639041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5044430.1244102382164.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Emanuel Muckenhuber resolved JBAS-6981.
---------------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Resolution: Done


> AttachmentStore MC bean (org.jboss.system.server.profileservice.repository.AbstractAttachmentStore) configuration does not specify the parameter type for constructor
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6981
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6981
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The profile.xml has this configuration for AttachmentStore:
> 	<bean name="AttachmentStore" class="org.jboss.system.server.profileservice.repository.AbstractAttachmentStore">
> 		<constructor><parameter><inject bean="BootstrapProfileFactory" property="attachmentStoreRoot" /></parameter></constructor>
> ....
> However, there are multiple constructors available for org.jboss.system.server.profileservice.repository.AbstractAttachmentStore. MC randomly picks up one of the available constructors and this can lead to exceptions as noted in the referenced forum thread.
> The fix is to provide the parameter type for the constructor in the MC bean configuration (note the use of class="java,io.File" for the constructor parameter):
> <bean name="AttachmentStore" class="org.jboss.system.server.profileservice.repository.AbstractAttachmentStore">
> 		<constructor><parameter class="java.io.File"><inject bean="BootstrapProfileFactory" property="attachmentStoreRoot" /></parameter></constructor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 04:02:03 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 4 Jun 2009 04:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6693) Add deployExploded
 argument to DeploymentManager.distribute()
In-Reply-To: <22761801.1238177902939.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14763648.1244102523743.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Emanuel Muckenhuber resolved JBAS-6693.
---------------------------------------

    Resolution: Done


As mentioned on the forums, i've added some DeploymentOptions to enable this. The usage would be something like:

getDeploymentManager().distribute(deployment, deploymentURL, new DeploymentOption[] { DeploymentOption.Explode });

> Add deployExploded argument to DeploymentManager.distribute()
> -------------------------------------------------------------
>
>                 Key: JBAS-6693
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6693
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Charles Crouch
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> It would be helpful if we could tell the DeploymentManager to expand the archive when its deployed, since linked issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 04:03:57 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 4 Jun 2009 04:03:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6758) Entering Global
 JNDI name in
 embedded console for new ConnectionFactory results in FileNotFoundException
In-Reply-To: <28783847.1239229102427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32983321.1244102637130.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Emanuel Muckenhuber resolved JBAS-6758.
---------------------------------------

    Resolution: Done


This should be fixed as well.

> Entering Global JNDI name in embedded console for new ConnectionFactory results in FileNotFoundException
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6758
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6758
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Shelly McGowan
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When entering a Global JNDI name using
> eis/ejb_Deployment, an attempt to create the new resource results in the following Exception.  Using ejb_Deployment only is successful.
> Failed to add Resource (see app server log for additional details): java.lang.RuntimeException:Failed to process template. -> java.lang.RuntimeException:java.io.FileNotFoundException: /TEST/Branch_5_x/build/output/jboss-5.1.0.CR1/server/all/deploy/eis/ejb_Deployment-ds.xml (No such file or directory) -> java.io.FileNotFoundException:/TEST/Branch_5_x/build/output/jboss-5.1.0.CR1/server/all/deploy/eis/ejb_Deployment-ds.xml (No such file or directory) 
> Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: /TEST/Branch_5_x/build/output/jboss-5.1.0.CR1/server/all/deploy/eis/ejb_Deployment_whitebox-tx.rar-ds.xml (No such file or directory)
>         at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.transferDeployment(StreamingDeploymentTarget.java:287)
>         at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.distribute(StreamingDeploymentTarget.java:107)
>         at org.jboss.profileservice.management.upload.DeploymentProgressImpl.distribute(DeploymentProgressImpl.java:177)
>         at org.jboss.profileservice.management.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:82)
>         at org.jboss.profileservice.management.AbstractTemplateCreator.distribute(AbstractTemplateCreator.java:158)
>         at org.jboss.profileservice.management.AbstractTemplateCreator.applyTemplate(AbstractTemplateCreator.java:99)
>         at org.jboss.profileservice.management.ManagementViewImpl.applyTemplate(ManagementViewImpl.java:1005)
> <snip>
> Caused by: java.io.FileNotFoundException: /TEST/Branch_5_x/build/output/jboss-5.1.0.CR1/server/all/deploy/eis/ejb_Deployment_whitebox-tx.rar-ds.xml (No such file or directory)
>         at java.io.FileOutputStream.open(Native Method)
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
>         at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.addDeploymentContent(BasicDeploymentRepository.java:147)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 04:53:56 2009
From: jira-events at lists.jboss.org (Dmitri Voronov (JIRA))
Date: Thu, 4 Jun 2009 04:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBJCA-94) Reauthentication
	support
In-Reply-To: <11499795.1242049679393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1870009.1244105636795.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Dmitri Voronov commented on JBJCA-94:
-------------------------------------

Since JCA specification addresses reauthentication responsibilities to both server and resource adapter, its implementation can be considered separately. In my opinion there should be two different tasks:
First of all the JBoss JCA has to provide reauthentication support, if a certain resource adapter; and it could be a third party resource adapter, does support. The JBoss JCA has to recognize this ability by interpreting of the ra.xml and provide an appropriate pooling and handling for Managed Connections.
The second task is to implement reauthentication in JBoss own resource adapters like JDBC.

>From my point of view the first task is most important, since the third party resource adapter depend on this feature. This will help to avoid such scenarios mentioned in the forum topic. I assume that an implementation of this feature in JBoss JCA is not so difficult.

> Reauthentication support
> ------------------------
>
>                 Key: JBJCA-94
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-94
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Core
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>
> Implement reauthentication support.
> See chapter 8 and related security discussions for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 05:18:59 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 4 Jun 2009 05:18:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-205) element name
 shouldn't be assigned to schemaLocation if namespace is not null
Message-ID: <17084352.1244107139708.JavaMail.jira@cloud.prod.atl2.jboss.com>

element name shouldn't be assigned to schemaLocation if namespace is not null
-----------------------------------------------------------------------------

                 Key: JBXB-205
                 URL: https://jira.jboss.org/jira/browse/JBXB-205
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.1.GA
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossXB-2.0.2.GA


In SundayContentHandler before schema resolution if schemaLocation was not provided in XML and DTD systemId is not available, schemaLocation is assigned to the localName of the element. This is useful for XML files that are validated against DTDs (or don't use a specific namespace). But if the namespace is not null there comes a problem since non-null schema location will override the one used in JBossEntityResolver (making mapping of nsURI to schemaLocation in the resolver useless).
So, assigning schemaLocation to localName should be done only for schemas that don't use namespaces.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 05:22:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 4 Jun 2009 05:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-205) element name shouldn't
 be assigned to schemaLocation if namespace is not null
In-Reply-To: <17084352.1244107139708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14470541.1244107376687.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Alexey Loubyansky closed JBXB-205.
----------------------------------

    Resolution: Done


Done.

> element name shouldn't be assigned to schemaLocation if namespace is not null
> -----------------------------------------------------------------------------
>
>                 Key: JBXB-205
>                 URL: https://jira.jboss.org/jira/browse/JBXB-205
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> In SundayContentHandler before schema resolution if schemaLocation was not provided in XML and DTD systemId is not available, schemaLocation is assigned to the localName of the element. This is useful for XML files that are validated against DTDs (or don't use a specific namespace). But if the namespace is not null there comes a problem since non-null schema location will override the one used in JBossEntityResolver (making mapping of nsURI to schemaLocation in the resolver useless).
> So, assigning schemaLocation to localName should be done only for schemas that don't use namespaces.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 05:25:23 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 4 Jun 2009 05:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6655) Upgrade AOP to
	2.1.1.GA
In-Reply-To: <31461795.1237807222491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8690304.1244107523045.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Kabir Khan updated JBAS-6655:
-----------------------------

    Summary: Upgrade AOP to 2.1.1.GA  (was: Upgrade AOP to 2.1.0.GA)


> Upgrade AOP to 2.1.1.GA
> -----------------------
>
>                 Key: JBAS-6655
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6655
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 05:40:56 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 4 Jun 2009 05:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-6655) Upgrade AOP to
	2.1.1.GA
In-Reply-To: <31461795.1237807222491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1987510.1244108456510.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Kabir Khan closed JBAS-6655.
----------------------------

    Resolution: Done


> Upgrade AOP to 2.1.1.GA
> -----------------------
>
>                 Key: JBAS-6655
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6655
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 05:40:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 4 Jun 2009 05:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-973)
 DistributedLockManager: lock()
 should block for timeout ms until it can acquire lock
In-Reply-To: <26784780.1241588866577.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7143642.1244108456664.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban updated JGRP-973:
--------------------------

    Fix Version/s: 3.x
                       (was: 2.8)


This requires too many changes, moved to 3.x. Maybe this feature will be provided by a complete rewrite of DLM

> DistributedLockManager: lock() should block for timeout ms until it can acquire lock
> ------------------------------------------------------------------------------------
>
>                 Key: JGRP-973
>                 URL: https://jira.jboss.org/jira/browse/JGRP-973
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.x
>
>
> Currently, lock() throw an exception *immediately* if the lock is held by someone else. It doesn't respect the timeout parameter, change this. This might be possible by picking a different VotingAdapter, have to investigate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 06:05:56 2009
From: jira-events at lists.jboss.org (Hans-Joerg Adel (JIRA))
Date: Thu, 4 Jun 2009 06:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-83)
 NullPointerException in Handler#getType
Message-ID: <2275005.1244109956457.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointerException in Handler#getType
---------------------------------------

                 Key: JASSIST-83
                 URL: https://jira.jboss.org/jira/browse/JASSIST-83
             Project: Javassist
          Issue Type: Bug
         Environment: JA version 3.4, Windows Vista and JDK 1.6.0_10
            Reporter: Hans-Joerg Adel
            Assignee: Shigeru Chiba
            Priority: Optional


Hi!

When I use ExprEditor#edit(Handler) to access a try-statement without a catch-clause I get a NullPointerException. 

To reproduce the bug, please use this source

/*--- (C) 1999-2008 Techniker Krankenkasse ---*/

package samplepackage;

import javassist.CannotCompileException;
import javassist.ClassPool;
import javassist.CtClass;
import javassist.NotFoundException;

import javassist.expr.ExprEditor;
import javassist.expr.Handler;

public class Sample {
	public static void main(String[] args) throws NotFoundException, CannotCompileException {
		ClassPool classPool = ClassPool.getDefault();
		CtClass ctClass = classPool.get("samplepackage.SampleClass");
		ctClass.instrument(new MyExprEditor());

	}

	static class MyExprEditor extends ExprEditor {
		@Override
		public void edit(Handler h) throws CannotCompileException {
			try {
				h.getType();
			} catch (NotFoundException e) {
			}
		}
	}
}



Stacktrace:
Exception in thread "main" java.lang.NullPointerException
	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:517)
	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:499)
	at javassist.expr.Handler.getType(Handler.java:76)
	at samplepackage.Sample$MyExprEditor.edit(Sample.java:25)
	at javassist.expr.ExprEditor.doit(ExprEditor.java:97)
	at javassist.CtClassType.instrument(CtClassType.java:1224)
	at samplepackage.Sample.main(Sample.java:17)

I would expect that h.getType() returns null.

I am using JA version 3.4, Windows Vista and JDK 1.6.0_10.

Cheers
Ruwen
iA Hans-Joerg Adel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 06:54:56 2009
From: jira-events at lists.jboss.org (Hans-Joerg Adel (JIRA))
Date: Thu, 4 Jun 2009 06:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-83)
 NullPointerException in Handler#getType
In-Reply-To: <2275005.1244109956457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5539798.1244112896677.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Hans-Joerg Adel updated JASSIST-83:
-----------------------------------

    Attachment: SampleClass.java


Forgotten

> NullPointerException in Handler#getType
> ---------------------------------------
>
>                 Key: JASSIST-83
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-83
>             Project: Javassist
>          Issue Type: Bug
>         Environment: JA version 3.4, Windows Vista and JDK 1.6.0_10
>            Reporter: Hans-Joerg Adel
>            Assignee: Shigeru Chiba
>            Priority: Optional
>         Attachments: SampleClass.java
>
>
> Hi!
> When I use ExprEditor#edit(Handler) to access a try-statement without a catch-clause I get a NullPointerException. 
> To reproduce the bug, please use this source
> /*--- (C) 1999-2008 Techniker Krankenkasse ---*/
> package samplepackage;
> import javassist.CannotCompileException;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.NotFoundException;
> import javassist.expr.ExprEditor;
> import javassist.expr.Handler;
> public class Sample {
> 	public static void main(String[] args) throws NotFoundException, CannotCompileException {
> 		ClassPool classPool = ClassPool.getDefault();
> 		CtClass ctClass = classPool.get("samplepackage.SampleClass");
> 		ctClass.instrument(new MyExprEditor());
> 	}
> 	static class MyExprEditor extends ExprEditor {
> 		@Override
> 		public void edit(Handler h) throws CannotCompileException {
> 			try {
> 				h.getType();
> 			} catch (NotFoundException e) {
> 			}
> 		}
> 	}
> }
> Stacktrace:
> Exception in thread "main" java.lang.NullPointerException
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:517)
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:499)
> 	at javassist.expr.Handler.getType(Handler.java:76)
> 	at samplepackage.Sample$MyExprEditor.edit(Sample.java:25)
> 	at javassist.expr.ExprEditor.doit(ExprEditor.java:97)
> 	at javassist.CtClassType.instrument(CtClassType.java:1224)
> 	at samplepackage.Sample.main(Sample.java:17)
> I would expect that h.getType() returns null.
> I am using JA version 3.4, Windows Vista and JDK 1.6.0_10.
> Cheers
> Ruwen
> iA Hans-Joerg Adel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 06:56:56 2009
From: jira-events at lists.jboss.org (Hans-Joerg Adel (JIRA))
Date: Thu, 4 Jun 2009 06:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-83)
 NullPointerException in Handler#getType
In-Reply-To: <2275005.1244109956457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31443905.1244113016465.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Hans-Joerg Adel updated JASSIST-83:
-----------------------------------

    Attachment: Sample.java


Completeness

> NullPointerException in Handler#getType
> ---------------------------------------
>
>                 Key: JASSIST-83
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-83
>             Project: Javassist
>          Issue Type: Bug
>         Environment: JA version 3.4, Windows Vista and JDK 1.6.0_10
>            Reporter: Hans-Joerg Adel
>            Assignee: Shigeru Chiba
>            Priority: Optional
>         Attachments: Sample.java, SampleClass.java
>
>
> Hi!
> When I use ExprEditor#edit(Handler) to access a try-statement without a catch-clause I get a NullPointerException. 
> To reproduce the bug, please use this source
> /*--- (C) 1999-2008 Techniker Krankenkasse ---*/
> package samplepackage;
> import javassist.CannotCompileException;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.NotFoundException;
> import javassist.expr.ExprEditor;
> import javassist.expr.Handler;
> public class Sample {
> 	public static void main(String[] args) throws NotFoundException, CannotCompileException {
> 		ClassPool classPool = ClassPool.getDefault();
> 		CtClass ctClass = classPool.get("samplepackage.SampleClass");
> 		ctClass.instrument(new MyExprEditor());
> 	}
> 	static class MyExprEditor extends ExprEditor {
> 		@Override
> 		public void edit(Handler h) throws CannotCompileException {
> 			try {
> 				h.getType();
> 			} catch (NotFoundException e) {
> 			}
> 		}
> 	}
> }
> Stacktrace:
> Exception in thread "main" java.lang.NullPointerException
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:517)
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:499)
> 	at javassist.expr.Handler.getType(Handler.java:76)
> 	at samplepackage.Sample$MyExprEditor.edit(Sample.java:25)
> 	at javassist.expr.ExprEditor.doit(ExprEditor.java:97)
> 	at javassist.CtClassType.instrument(CtClassType.java:1224)
> 	at samplepackage.Sample.main(Sample.java:17)
> I would expect that h.getType() returns null.
> I am using JA version 3.4, Windows Vista and JDK 1.6.0_10.
> Cheers
> Ruwen
> iA Hans-Joerg Adel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 07:37:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 4 Jun 2009 07:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1637) Interruption
	is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17119922.1244115476521.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao closed JBMESSAGING-1637.
-----------------------------------

    Resolution: Done


done

> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 07:41:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 4 Jun 2009 07:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-721) Binds with similar
 pointcut expressions are ignored
In-Reply-To: <10693694.1239946822969.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10889656.1244115716762.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAOP-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470592#action_12470592 ] 

Carlo de Wolf commented on JBAOP-721:
-------------------------------------

In another setup:
13:33:53,133 DEBUG [Aspect] Bound aspect org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor; deployed:true
13:33:55,889 DEBUG [Aspect] Bound aspect org.jboss.ejb3.test.tx.common.SessionSynchronizationInterceptor; deployed:true
13:33:58,073 DEBUG [Aspect] Bound aspect org.jboss.ejb3.test.tx.common.StatefulInstanceInterceptor; deployed:true
13:34:00,223 DEBUG [Aspect] Bound aspect org.jboss.ejb3.tx.BMTTxInterceptorFactory; deployed:true
13:34:02,989 DEBUG [Aspect] Bound aspect org.jboss.ejb3.tx.CMTTxInterceptorFactory; deployed:true
13:34:04,956 DEBUG [Aspect] Bound aspect org.jboss.ejb3.tx.RetryingInterceptor; deployed:true
13:34:07,415 DEBUG [Aspect] Bound aspect org.jboss.ejb3.test.tx.common.SynchronizationActionInterceptor; deployed:true
13:34:14,853 DEBUG [AspectBinding] Bound binding 3j001-dcvc15-fvje2q5e-1-fvje2szj-4
13:34:20,389 DEBUG [AspectBinding] Bound binding 3j001-dcvc15-fvje2q5e-1-fvje2szo-5
13:34:22,835 DEBUG [AspectBinding] Bound binding 3j001-dcvc15-fvje2q5e-1-fvje2szp-6
13:38:57,546 DEBUG [AspectBinding] Bound binding 3j001-dcvc15-fvje2q5e-1-fvje2szq-8
13:38:59,271 DEBUG [AspectBinding] Bound binding 3j001-dcvc15-fvje2q5e-1-fvje2szr-9

For some reason MC doesn't start the 7th advice binding, but since there is no check whether the deployment is complete, the reason remains unknown.

> Binds with similar pointcut expressions are ignored
> ---------------------------------------------------
>
>                 Key: JBAOP-721
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-721
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.0.GA
>         Environment: Branch_5_x @ 87425
>            Reporter: Carlo de Wolf
>            Assignee: Flavia Rainone
>            Priority: Critical
>             Fix For: 2.1.2.GA, 2.2.0.GA
>
>
> Given the following descriptor:
> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/trunk/core/src/main/resources/ejb3-interceptors-aop.xml?revision=87350&view=markup
> 04-16-2009 09:47:58:  ERROR: java.lang.NullPointerException
>     at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
>     at org.jboss.ejb3.tx.TxInterceptor$Never.invoke(TxInterceptor.java:63)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:560)
>     at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>     at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91) 
> StatefulInstanceInterceptor is not executed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 08:06:17 2009
From: jira-events at lists.jboss.org (Martin Vecera (JIRA))
Date: Thu, 4 Jun 2009 08:06:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6328) jmx-console: Back
 to MBean button causes error
In-Reply-To: <29723732.1229531464862.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12663232.1244117177940.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Martin Vecera reassigned JBAS-6328:
-----------------------------------

    Assignee: Dimitris Andreadis  (was: Farah Juma)


Dimitris, could you please close the issue if it is verified? I found that one by chance and I don't have enough time to give it a try right now...

> jmx-console: Back to MBean button causes error
> ----------------------------------------------
>
>                 Key: JBAS-6328
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6328
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX/Web Console
>    Affects Versions: JBossAS-5.0.0.GA
>            Reporter: Martin Vecera
>            Assignee: Dimitris Andreadis
>            Priority: Critical
>             Fix For: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: ApplyChangesButton.patch, JBAS-6328.patch
>
>
> After invoking an operation in JMX Console (e.g. startDatabaseManager under http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB), the button "Back to MBean" on result page causes Error 500.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 08:22:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 4 Jun 2009 08:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-721) Binds with similar
 pointcut expressions are ignored
In-Reply-To: <10693694.1239946822969.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24153204.1244118176573.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAOP-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470601#action_12470601 ] 

Carlo de Wolf commented on JBAOP-721:
-------------------------------------

By using the regular BeanDeployer instead of AbstractAopMetaDataDeployer.deployBeans (which is bad) I get:

org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

DEPLOYMENTS MISSING DEPENDENCIES:
  Deployment "3j001-jm9okg-fvjfr10d-1-fvjfr3r7-7" is missing the following dependencies:
    Dependency "3j001-jm9okg-fvjfr10d-1-fvjfr3r7-7$2" (should be in state "Configured", but is actually in state "Instantiated")
  Deployment "3j001-jm9okg-fvjfr10d-1-fvjfr3r7-7$2" is missing the following dependencies:
    Dependency "org.jboss.ejb3.tx.test.common.SynchronizationActionInterceptor" (should be in state "Configured", but is actually in state "** NOT FOUND Depends on 'org.jboss.ejb3.tx.test.common.SynchronizationActionInterceptor' **")

DEPLOYMENTS IN ERROR:
  Deployment "org.jboss.ejb3.tx.test.common.SynchronizationActionInterceptor" is in error due to the following reason(s): ** NOT FOUND Depends on 'org.jboss.ejb3.tx.test.common.SynchronizationActionInterceptor' **


> Binds with similar pointcut expressions are ignored
> ---------------------------------------------------
>
>                 Key: JBAOP-721
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-721
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.0.GA
>         Environment: Branch_5_x @ 87425
>            Reporter: Carlo de Wolf
>            Assignee: Flavia Rainone
>            Priority: Critical
>             Fix For: 2.1.2.GA, 2.2.0.GA
>
>
> Given the following descriptor:
> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/trunk/core/src/main/resources/ejb3-interceptors-aop.xml?revision=87350&view=markup
> 04-16-2009 09:47:58:  ERROR: java.lang.NullPointerException
>     at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
>     at org.jboss.ejb3.tx.TxInterceptor$Never.invoke(TxInterceptor.java:63)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:560)
>     at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>     at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91) 
> StatefulInstanceInterceptor is not executed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 08:51:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 4 Jun 2009 08:51:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-721) Binds with similar
 pointcut expressions are ignored
In-Reply-To: <10693694.1239946822969.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23824140.1244119916593.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAOP-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470605#action_12470605 ] 

Carlo de Wolf commented on JBAOP-721:
-------------------------------------

Ah, I have an interceptor-ref to a non-existent interceptor.

<interceptor class="org.jboss.ejb3.test.tx.common.SynchronizationActionInterceptor" scope="PER_VM"/>

<interceptor-ref name="org.jboss.ejb3.tx.test.common.SynchronizationActionInterceptor"/>

Both the deployment of beans and the a proper error for this scenario must be fixed.

> Binds with similar pointcut expressions are ignored
> ---------------------------------------------------
>
>                 Key: JBAOP-721
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-721
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.0.GA
>         Environment: Branch_5_x @ 87425
>            Reporter: Carlo de Wolf
>            Assignee: Flavia Rainone
>            Priority: Critical
>             Fix For: 2.1.2.GA, 2.2.0.GA
>
>
> Given the following descriptor:
> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/trunk/core/src/main/resources/ejb3-interceptors-aop.xml?revision=87350&view=markup
> 04-16-2009 09:47:58:  ERROR: java.lang.NullPointerException
>     at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
>     at org.jboss.ejb3.tx.TxInterceptor$Never.invoke(TxInterceptor.java:63)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:560)
>     at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>     at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91) 
> StatefulInstanceInterceptor is not executed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 09:48:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Thu, 4 Jun 2009 09:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2108) A rule does not
 fire for all objects satisfying the rule code.
Message-ID: <23289330.1244123336579.JavaMail.jira@cloud.prod.atl2.jboss.com>

A rule does not fire for all objects satisfying the rule code.
--------------------------------------------------------------

                 Key: JBRULES-2108
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2108
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 4.0.7
            Reporter: Andrey Nechaev
            Assignee: Mark Proctor


The following code shows the problem:
public class DroolsTest {
	private final static int NUM_FACTS = 20;
	private final static String rule = "" + 
		"package test\n" + 
		"import com.test.DroolsTest;\n" + 
		"import com.test.DroolsTest.Foo;\n" +
		"import com.test.DroolsTest.Bar;\n" +
		"rule test\n" + 
			"\twhen\n" + 
				"\t\tFoo($p : id < " + Integer.toString(NUM_FACTS) + ") && Bar(id == $p)\n" +
			"\tthen\n" +
				"\t\tDroolsTest.incCounter();\n" +
		"end";
	
	private static int counter;
	
	public static class Foo {
		private final int id;
		
		Foo(int id) {
			this.id = id;
		}
		
		public int getId() {
			return id;
		}
	}
	
	public static class Bar {
		private final int id;
		
		Bar(int id) {
			this.id = id;
		}
		
		public int getId() {
			return id;
		}
	}
	
	public static void main(String[] args) throws Exception {
		RuleBase rb;
		WorkingMemory wm;
		counter = 0;
		
		rb = RuleBaseFactory.newRuleBase();
		wm = rb.newStatefulSession();
				
		for(int i = 0; i < NUM_FACTS; i++) {
			wm.insert(new Foo(i));
			wm.insert(new Bar(i));
		}
		PackageBuilder bld = new PackageBuilder();
		bld.addPackageFromDrl(new StringReader(rule));
		
		rb.addPackage(bld.getPackage());
		System.out.println(counter == NUM_FACTS ? "passed" : "failed");
	}
	
	public static void incCounter() {
		++counter;
	}
}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 09:52:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Thu, 4 Jun 2009 09:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2108) A rule does not
 fire for all objects satisfying the rule code.
In-Reply-To: <23289330.1244123336579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32419810.1244123576472.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrey Nechaev commented on JBRULES-2108:
-----------------------------------------

It seems there is a bug in the FieldIndexHashTableFullIterator iterator's next() method. When a table's item contains more than one element, all the elements except the first one are skipped. Attachement is the patch resolving the issue, and it works in our environment.

> A rule does not fire for all objects satisfying the rule code.
> --------------------------------------------------------------
>
>                 Key: JBRULES-2108
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2108
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 4.0.7
>            Reporter: Andrey Nechaev
>            Assignee: Mark Proctor
>
> The following code shows the problem:
> public class DroolsTest {
> 	private final static int NUM_FACTS = 20;
> 	private final static String rule = "" + 
> 		"package test\n" + 
> 		"import com.test.DroolsTest;\n" + 
> 		"import com.test.DroolsTest.Foo;\n" +
> 		"import com.test.DroolsTest.Bar;\n" +
> 		"rule test\n" + 
> 			"\twhen\n" + 
> 				"\t\tFoo($p : id < " + Integer.toString(NUM_FACTS) + ") && Bar(id == $p)\n" +
> 			"\tthen\n" +
> 				"\t\tDroolsTest.incCounter();\n" +
> 		"end";
> 	
> 	private static int counter;
> 	
> 	public static class Foo {
> 		private final int id;
> 		
> 		Foo(int id) {
> 			this.id = id;
> 		}
> 		
> 		public int getId() {
> 			return id;
> 		}
> 	}
> 	
> 	public static class Bar {
> 		private final int id;
> 		
> 		Bar(int id) {
> 			this.id = id;
> 		}
> 		
> 		public int getId() {
> 			return id;
> 		}
> 	}
> 	
> 	public static void main(String[] args) throws Exception {
> 		RuleBase rb;
> 		WorkingMemory wm;
> 		counter = 0;
> 		
> 		rb = RuleBaseFactory.newRuleBase();
> 		wm = rb.newStatefulSession();
> 				
> 		for(int i = 0; i < NUM_FACTS; i++) {
> 			wm.insert(new Foo(i));
> 			wm.insert(new Bar(i));
> 		}
> 		PackageBuilder bld = new PackageBuilder();
> 		bld.addPackageFromDrl(new StringReader(rule));
> 		
> 		rb.addPackage(bld.getPackage());
> 		System.out.println(counter == NUM_FACTS ? "passed" : "failed");
> 	}
> 	
> 	public static void incCounter() {
> 		++counter;
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 09:54:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Thu, 4 Jun 2009 09:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2108) A rule does not
 fire for all objects satisfying the rule code.
In-Reply-To: <23289330.1244123336579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23826105.1244123696504.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrey Nechaev updated JBRULES-2108:
------------------------------------

    Attachment: patch


> A rule does not fire for all objects satisfying the rule code.
> --------------------------------------------------------------
>
>                 Key: JBRULES-2108
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2108
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 4.0.7
>            Reporter: Andrey Nechaev
>            Assignee: Mark Proctor
>         Attachments: patch
>
>
> The following code shows the problem:
> public class DroolsTest {
> 	private final static int NUM_FACTS = 20;
> 	private final static String rule = "" + 
> 		"package test\n" + 
> 		"import com.test.DroolsTest;\n" + 
> 		"import com.test.DroolsTest.Foo;\n" +
> 		"import com.test.DroolsTest.Bar;\n" +
> 		"rule test\n" + 
> 			"\twhen\n" + 
> 				"\t\tFoo($p : id < " + Integer.toString(NUM_FACTS) + ") && Bar(id == $p)\n" +
> 			"\tthen\n" +
> 				"\t\tDroolsTest.incCounter();\n" +
> 		"end";
> 	
> 	private static int counter;
> 	
> 	public static class Foo {
> 		private final int id;
> 		
> 		Foo(int id) {
> 			this.id = id;
> 		}
> 		
> 		public int getId() {
> 			return id;
> 		}
> 	}
> 	
> 	public static class Bar {
> 		private final int id;
> 		
> 		Bar(int id) {
> 			this.id = id;
> 		}
> 		
> 		public int getId() {
> 			return id;
> 		}
> 	}
> 	
> 	public static void main(String[] args) throws Exception {
> 		RuleBase rb;
> 		WorkingMemory wm;
> 		counter = 0;
> 		
> 		rb = RuleBaseFactory.newRuleBase();
> 		wm = rb.newStatefulSession();
> 				
> 		for(int i = 0; i < NUM_FACTS; i++) {
> 			wm.insert(new Foo(i));
> 			wm.insert(new Bar(i));
> 		}
> 		PackageBuilder bld = new PackageBuilder();
> 		bld.addPackageFromDrl(new StringReader(rule));
> 		
> 		rb.addPackage(bld.getPackage());
> 		System.out.println(counter == NUM_FACTS ? "passed" : "failed");
> 	}
> 	
> 	public static void incCounter() {
> 		++counter;
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:08:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Thu, 4 Jun 2009 10:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2392) Selenium tests
	for XSS
In-Reply-To: <23069268.1242226847011.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8499719.1244124536796.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470622#action_12470622 ] 

Viliam Rockai commented on JBPORTAL-2392:
-----------------------------------------

Qestions:

Identity admin: It is needed to add XSS testing to search input in identity admin? no error message is popped up and the user (xss string) is not found of course
WSRP: producer configuration - typing a string into Registration policy class name gives me an error, but typiing it into Registration property validator class name does not. everything seems to work but the error message is missing. is it ok?



> Selenium tests for XSS
> ----------------------
>
>                 Key: JBPORTAL-2392
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2392
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal QA
>            Reporter: Viliam Rockai
>            Assignee: Viliam Rockai
>
> Testing XSS on inputs in portal GUI had to be implemented.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:14:57 2009
From: jira-events at lists.jboss.org (Graham Gear (JIRA))
Date: Thu, 4 Jun 2009 10:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2109) Upload of
 Resource to Guvnor
 with multiple "." in file name causes resource type identification issues
Message-ID: <20350008.1244124897030.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upload of Resource to Guvnor with multiple "." in file name causes resource type identification issues
------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2109
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2109
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-guvnor
    Affects Versions: 5.0.1.FINAL
            Reporter: Graham Gear
            Assignee: Mark Proctor
            Priority: Minor


It seems the resource type identification is based on the file suffix of the resource being uploaded but matches against the first, not last "." in the filename to determine the suffix. This causes issue if the resource includes multiple "." which is valid under most file systems. It is also common for model JARs to include a version number with an extra ".", eg:

application-model-1.0.0.jar

The issue can be reproduced by uploading a model, DRL, RF etc to the Guvnor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:18:56 2009
From: jira-events at lists.jboss.org (Graham Gear (JIRA))
Date: Thu, 4 Jun 2009 10:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2109) Upload of
 Resource to Guvnor
 with multiple "." in file name causes resource type identification issues
In-Reply-To: <20350008.1244124897030.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26376719.1244125136574.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Graham Gear updated JBRULES-2109:
---------------------------------


Note that this is also evident from the WebDAV interfaces (JBoss Dev Studio / Cadaver etc)

> Upload of Resource to Guvnor with multiple "." in file name causes resource type identification issues
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2109
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2109
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Graham Gear
>            Assignee: Mark Proctor
>            Priority: Minor
>
> It seems the resource type identification is based on the file suffix of the resource being uploaded but matches against the first, not last "." in the filename to determine the suffix. This causes issue if the resource includes multiple "." which is valid under most file systems. It is also common for model JARs to include a version number with an extra ".", eg:
> application-model-1.0.0.jar
> The issue can be reproduced by uploading a model, DRL, RF etc to the Guvnor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:23:57 2009
From: jira-events at lists.jboss.org (Graham Gear (JIRA))
Date: Thu, 4 Jun 2009 10:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2110) Upload of
 RuleFlow with ".rf"
 suffix to Guvnor through WebDAV does not get correctly identified as a
 RuleFlow
Message-ID: <21846412.1244125437026.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow
-------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2110
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2110
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.1.FINAL
            Reporter: Graham Gear
            Assignee: Mark Proctor


Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow.

To reproduce, add a *.rf resource through JBoss Dev Studio or WebDAV client (eg cadaver) and see the resource get itemised incorrectly as a *.drl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:23:57 2009
From: jira-events at lists.jboss.org (Graham Gear (JIRA))
Date: Thu, 4 Jun 2009 10:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2110) Upload of
 RuleFlow with ".rf"
 suffix to Guvnor through WebDAV does not get correctly identified as a
 RuleFlow
In-Reply-To: <21846412.1244125437026.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32023092.1244125437215.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Graham Gear updated JBRULES-2110:
---------------------------------

    Component/s: drools-guvnor


> Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2110
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2110
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Graham Gear
>            Assignee: Mark Proctor
>
> Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow.
> To reproduce, add a *.rf resource through JBoss Dev Studio or WebDAV client (eg cadaver) and see the resource get itemised incorrectly as a *.drl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:27:57 2009
From: jira-events at lists.jboss.org (Martin Vecera (JIRA))
Date: Thu, 4 Jun 2009 10:27:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4211) Detecting
 OutOfMemoryErrors in Servers in the Test Suite
In-Reply-To: <28142178.1174172252579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29836505.1244125677795.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Martin Vecera reassigned JBAS-4211:
-----------------------------------

    Assignee: Shelly McGowan  (was: Martin Vecera)


Hello Shelly, I'm no longer working on this issue, and I don't think it's going to be finished ever.

> Detecting OutOfMemoryErrors in Servers in the Test Suite
> --------------------------------------------------------
>
>                 Key: JBAS-4211
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4211
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Ryan Campbell
>            Assignee: Shelly McGowan
>         Attachments: dist.tar.bz2
>
>   Original Estimate: 3 days
>          Time Spent: 2 days, 2 hours
>  Remaining Estimate: 6 hours
>
> We need a custom test runner which checks for OOME's in any running servers between each test.  Optionally, only check for this after a failed test.
> See the discussion for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:27:57 2009
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Thu, 4 Jun 2009 10:27:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2392) Selenium tests
	for XSS
In-Reply-To: <23069268.1242226847011.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20201470.1244125677388.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470628#action_12470628 ] 

Prabhat Jha commented on JBPORTAL-2392:
---------------------------------------

Yes, we need to add XSS tests for Identity admin as well.
For WSRP, it should add error in both places. But as long as it's not letting bad strings to go, it's okay.

> Selenium tests for XSS
> ----------------------
>
>                 Key: JBPORTAL-2392
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2392
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal QA
>            Reporter: Viliam Rockai
>            Assignee: Viliam Rockai
>
> Testing XSS on inputs in portal GUI had to be implemented.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:35:58 2009
From: jira-events at lists.jboss.org (Chris Kulinski (JIRA))
Date: Thu, 4 Jun 2009 10:35:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4012) ClassLoaderUtils
 recurses into .war directories
In-Reply-To: <28298238.1169670354541.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19246669.1244126158569.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Chris Kulinski commented on JBAS-4012:
--------------------------------------

David's fix works well for us.  For one application of ours, we've improved our JBoss startup time from 1 minute 30 seconds to 19 seconds using this fix.  That's amazing!

The only issue we encountered is that the patch that David submitted is actually backwards.  Below is the patch to ClassLoaderUtils.java that we're using.  The first 2 sections of diff are to add better trace logging.  You really only need the last section of diff for the actual fix.  This diff is from the JBoss 4.2.2.GA source.

Patch the source, compile the class and then update jboss-jmx.jar with the new ClassLoaderUtils$FileIterator.class.

--- ./jmx/src/main/org/jboss/mx/loading/ClassLoaderUtils.java   Wed Jun  3 15:00:46 2009
+++ ../jboss-jmx.jar/org/jboss/mx/loading/ClassLoaderUtils.java Tue Jun  2 16:54:34 2009
@@ -472,9 +472,10 @@
          String name = start.getName();
          // Don't recurse into wars
          boolean isWar = name.endsWith(".war");
-         if( isWar )
-            currentListing = new File[0];
-         else
+         if( isWar ) {
+         log.trace("war, not recursing");
+             currentListing = new File[0];
+         } else
             currentListing = start.listFiles();
       }
       FileIterator(File start, FileFilter filter)
@@ -482,9 +483,10 @@
          String name = start.getName();
          // Don't recurse into wars
          boolean isWar = name.endsWith(".war");
-         if( isWar )
-            currentListing = new File[0];
-         else
+         if( isWar ) {
+             log.trace("war, not recursing");
+             currentListing = new File[0];
+         } else
             currentListing = start.listFiles(filter);
          this.filter = filter;
       }
@@ -497,7 +499,11 @@
             do
             {
                File nextDir = (File) subDirectories.removeFirst();
-               currentListing = nextDir.listFiles(filter);
+               if(nextDir.getName().endsWith(".war")){
+                    currentListing = new File[0];
+               } else {
+                    currentListing = nextDir.listFiles(filter);
+               }
             } while( currentListing.length == 0 && subDirectories.size() > 0 );
             index = 0;
          }


> ClassLoaderUtils recurses into .war directories
> -----------------------------------------------
>
>                 Key: JBAS-4012
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4012
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: windows xp, java 1.5.0_09
>            Reporter: David
>            Assignee: Scott M Stark
>            Priority: Minor
>
> ClassLoaderUtils has logic that is supposed to prevent indexing/scanning of .war directories.  This was an issue fixed earlier in 3.2.6, reported in a support case: 00002351
> The following patch is also needed in order to fully prevent indexing in .war directories:
> $ diff -u src/org/jboss/mx/loading/ClassLoaderUtils.java /khub/opensource/jboss-4.0.5.GA-src/jmx/src/main/org/jboss/mx/loading/ClassLoaderUtils.java
> --- src/org/jboss/mx/loading/ClassLoaderUtils.java      2007-01-24 14:27:27.607071000 -0500
> +++ /khub/opensource/jboss-4.0.5.GA-src/jmx/src/main/org/jboss/mx/loading/ClassLoaderUtils.java 2006-10-16 23:37:24.000000000 -0400
> @@ -472,27 +472,21 @@
>           String name = start.getName();
>           // Don't recurse into wars
>           boolean isWar = name.endsWith(".war");
> -         if( isWar ) {
> -            log.trace("war, not recursing");
> +         if( isWar )
>              currentListing = new File[0];
> -         }
> -         else {
> +         else
>              currentListing = start.listFiles();
> -         }
>        }
>        FileIterator(File start, FileFilter filter)
>        {
>           String name = start.getName();
>           // Don't recurse into wars
>           boolean isWar = name.endsWith(".war");
> -         if( isWar ) {
> -            log.trace("war, not recursing");
> +         if( isWar )
>              currentListing = new File[0];
> -         }
> -         else {
> +         else
>              currentListing = start.listFiles(filter);
> -            this.filter = filter;
> -         }
> +         this.filter = filter;
>        }
>        File getNextEntry()
> @@ -503,13 +497,7 @@
>              do
>              {
>                 File nextDir = (File) subDirectories.removeFirst();
> -               if (nextDir.getName().endsWith(".war")) {
> -                  log.trace("war, not recursing");
> -                  currentListing = new File[0];
> -               }
> -               else {
> -                  currentListing = nextDir.listFiles(filter);
> -               }
> +               currentListing = nextDir.listFiles(filter);
>              } while( currentListing.length == 0 && subDirectories.size() > 0 );
>              index = 0;
>           }
> The stack trace during startup is here:
> "main" prio=6 tid=0x1bcadc70 nid=0xec4 runnable [0x1c02e000..0x1c02fb18]
> 	at java.io.WinNTFileSystem.list(Native Method)
> 	at java.io.File.list(File.java:937)
> 	at java.io.File.listFiles(File.java:1093)
> 	at org.jboss.mx.loading.ClassLoaderUtils$FileIterator.getNextEntry(ClassLoaderUtils.java:500)
> 	at org.jboss.mx.loading.ClassLoaderUtils$ClassPathIterator.getNextEntry(ClassLoaderUtils.java:617)
> 	at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap(ClassLoaderUtils.java:319)
> 	at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap(ClassLoaderUtils.java:253)
> 	at org.jboss.mx.loading.UnifiedLoaderRepository3.updatePackageMap(UnifiedLoaderRepository3.java:783)
> 	at org.jboss.mx.loading.UnifiedLoaderRepository3.addRepositoryClassLoader(UnifiedLoaderRepository3.java:740)
> 	- locked <0x07aafcf0> (a EDU.oswego.cs.dl.util.concurrent.CopyOnWriteArraySet)
> 	at org.jboss.mx.loading.UnifiedLoaderRepository3.addClassLoader(UnifiedLoaderRepository3.java:662)
> 	at org.jboss.mx.loading.UnifiedLoaderRepository3.registerClassLoader(UnifiedLoaderRepository3.java:946)
> 	at org.jboss.mx.loading.UnifiedLoaderRepository3.newClassLoader(UnifiedLoaderRepository3.java:168)
> 	at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.deployment.DeploymentInfo.createClassLoaders(DeploymentInfo.java:280)
> 	at org.jboss.deployment.MainDeployer.init(MainDeployer.java:874)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:809)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> 	at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	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:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy9.deploy(Unknown Source)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
> 	- locked <0x07e0e0d8> (a org.jboss.deployment.scanner.URLDeploymentScanner)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
> 	- locked <0x07ec9400> (a org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> 	at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> 	at $Proxy0.start(Unknown Source)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
> 	- locked <0x07af6660> (a org.jboss.system.ServiceController)
> 	at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy4.start(Unknown Source)
> 	at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	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:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy5.deploy(Unknown Source)
> 	at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
> 	at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
> 	at org.jboss.Main.boot(Main.java:200)
> 	at org.jboss.Main$1.run(Main.java:490)
> 	at java.lang.Thread.run(Thread.java:595)
> with trace logging on you see:

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:39:56 2009
From: jira-events at lists.jboss.org (Graham Gear (JIRA))
Date: Thu, 4 Jun 2009 10:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2110) Upload of
 RuleFlow with ".rf"
 suffix to Guvnor through WebDAV does not get correctly identified as a
 RuleFlow
In-Reply-To: <21846412.1244125437026.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16697068.1244126396725.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Graham Gear updated JBRULES-2110:
---------------------------------


Actually, this is not related to the resource type (*.rf) but the format of the file name being uploaded as per the examples below:

Local file name  -> Guvnor import via Dev Studio / Cadaver -> Guvnor Resource Name

SubmitApplication.rf   ->   ->  SubmitApplication.drl
Submit.rf   ->   ->  Submit.rf

This could be a category of greater issue within the resource identification code of the Guvnor.



> Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2110
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2110
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Graham Gear
>            Assignee: Mark Proctor
>
> Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow.
> To reproduce, add a *.rf resource through JBoss Dev Studio or WebDAV client (eg cadaver) and see the resource get itemised incorrectly as a *.drl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:46:56 2009
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 4 Jun 2009 10:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-6328) jmx-console: Back to
 MBean button causes error
In-Reply-To: <29723732.1229531464862.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <723396.1244126816789.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Dimitris Andreadis closed JBAS-6328.
------------------------------------



> jmx-console: Back to MBean button causes error
> ----------------------------------------------
>
>                 Key: JBAS-6328
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6328
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX/Web Console
>    Affects Versions: JBossAS-5.0.0.GA
>            Reporter: Martin Vecera
>            Assignee: Dimitris Andreadis
>            Priority: Critical
>             Fix For: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: ApplyChangesButton.patch, JBAS-6328.patch
>
>
> After invoking an operation in JMX Console (e.g. startDatabaseManager under http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB), the button "Back to MBean" on result page causes Error 500.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:49:56 2009
From: jira-events at lists.jboss.org (Guillaume Jeudy (JIRA))
Date: Thu, 4 Jun 2009 10:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-523) Implement
 topic hierarchies
In-Reply-To: <16561250.1155738026493.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28470976.1244126996891.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Guillaume Jeudy commented on JBMESSAGING-523:
---------------------------------------------

is there any documentation on how to use this feature in JBM 2.0 ?  I couldnt find any. Besides I only see a 2.0 alpha release but this JIRA states it was implemented in 2.0 beta...

> Implement topic hierarchies
> ---------------------------
>
>                 Key: JBMESSAGING-523
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-523
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Andy Taylor
>            Priority: Critical
>             Fix For: 2.0.0 Beta
>
>
> Implement topic hierarchies so a subscription can subscribe to a wildcard, e.g. news.* and will receive all messages sent to topics news.uk, news.usa, news.usa.local etc etc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:49:57 2009
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 4 Jun 2009 10:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2111) In-Pattern
 RestrictionConnectiveDescrs (&& and ||) do not support bindings and
 restrictions at the same time
Message-ID: <27444468.1244126997455.JavaMail.jira@cloud.prod.atl2.jboss.com>

In-Pattern RestrictionConnectiveDescrs (&& and ||) do not support bindings and restrictions at the same time
------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2111
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2111
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.1.FINAL, 5.0.0.FINAL, 5.0.0.CR1, 5.0.0.M5,  5.0.0.M4, 5.0.0.M3,  5.0.0.M2, 5.0.0.M1
         Environment: any
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Critical
             Fix For: FUTURE


when trying to use connectives with restrictions and bindings, as in :
       Type( $f1: field1 op1 expr1 && $f2 : field2 op2 expr2)
the fieldRestrictions are ignored by the parser and only the bindings are retained.
Thus, reading the values of $f1 or $f2 returns the right value, but the restrictions
(field op expr) are not generated

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:52:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 4 Jun 2009 10:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2111) In-Pattern
 RestrictionConnectiveDescrs (&& and ||) do not support bindings and
 restrictions at the same time
In-Reply-To: <27444468.1244126997455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16584045.1244127176548.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli reassigned JBRULES-2111:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> In-Pattern RestrictionConnectiveDescrs (&& and ||) do not support bindings and restrictions at the same time
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2111
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2111
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.0.0.M1,  5.0.0.M2, 5.0.0.M3,  5.0.0.M4, 5.0.0.M5, 5.0.0.CR1, 5.0.0.FINAL, 5.0.1.FINAL
>         Environment: any
>            Reporter: Davide Sottara
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: FUTURE
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> when trying to use connectives with restrictions and bindings, as in :
>        Type( $f1: field1 op1 expr1 && $f2 : field2 op2 expr2)
> the fieldRestrictions are ignored by the parser and only the bindings are retained.
> Thus, reading the values of $f1 or $f2 returns the right value, but the restrictions
> (field op expr) are not generated

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:54:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 4 Jun 2009 10:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2111) In-Pattern
 RestrictionConnectiveDescrs (&& and ||) do not support bindings and
 restrictions at the same time
In-Reply-To: <27444468.1244126997455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18473120.1244127296522.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli updated JBRULES-2111:
-----------------------------------

        Fix Version/s: 5.1.0.M1
                           (was: FUTURE)
    Affects Version/s:     (was: 5.0.0.M1)
                           (was:  5.0.0.M2)


> In-Pattern RestrictionConnectiveDescrs (&& and ||) do not support bindings and restrictions at the same time
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2111
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2111
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.0.0.M3,  5.0.0.M4, 5.0.0.M5, 5.0.0.CR1, 5.0.0.FINAL, 5.0.1.FINAL
>         Environment: any
>            Reporter: Davide Sottara
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.1.0.M1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> when trying to use connectives with restrictions and bindings, as in :
>        Type( $f1: field1 op1 expr1 && $f2 : field2 op2 expr2)
> the fieldRestrictions are ignored by the parser and only the bindings are retained.
> Thus, reading the values of $f1 or $f2 returns the right value, but the restrictions
> (field op expr) are not generated

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:56:56 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Thu, 4 Jun 2009 10:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-523) Implement
 topic hierarchies
In-Reply-To: <16561250.1155738026493.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11183527.1244127416609.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andy Taylor commented on JBMESSAGING-523:
-----------------------------------------

jbm 2 beta has not been released yet altho its imminent. This will contain documentation on how to use it.

> Implement topic hierarchies
> ---------------------------
>
>                 Key: JBMESSAGING-523
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-523
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Andy Taylor
>            Priority: Critical
>             Fix For: 2.0.0 Beta
>
>
> Implement topic hierarchies so a subscription can subscribe to a wildcard, e.g. news.* and will receive all messages sent to topics news.uk, news.usa, news.usa.local etc etc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 11:01:01 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 4 Jun 2009 11:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-523) Implement
 topic hierarchies
In-Reply-To: <16561250.1155738026493.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31408497.1244127661247.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox commented on JBMESSAGING-523:
-------------------------------------

If you can't wait, then this is in SVN TRUNK

> Implement topic hierarchies
> ---------------------------
>
>                 Key: JBMESSAGING-523
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-523
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Andy Taylor
>            Priority: Critical
>             Fix For: 2.0.0 Beta
>
>
> Implement topic hierarchies so a subscription can subscribe to a wildcard, e.g. news.* and will receive all messages sent to topics news.uk, news.usa, news.usa.local etc etc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 11:07:09 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 4 Jun 2009 11:07:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1844) Retry operations
 after an EJBTransactionRolledbackException
Message-ID: <16255062.1244128029237.JavaMail.jira@cloud.prod.atl2.jboss.com>

Retry operations after an EJBTransactionRolledbackException
-----------------------------------------------------------

                 Key: EJBTHREE-1844
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1844
             Project: EJB 3.0
          Issue Type: Feature Request
          Components: transactions
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf


By either annotating a bean or its methods, the applicable methods will retry the operation if an EJBTransactionRolledbackException occurs.
@TransactionRetry(numRetries=4, waitTime=1, waitTimeUnit=TimeUnit.SECONDS)

numRetries specifies how many times an operation will be tried.
waitTime specified the amount of time to wait before retrying with the unit of time specified in waitTimeUnit.

Default is 3 retries and 1000 milliseconds wait time after an EJBTransactionRolledbackException.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 11:12:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 4 Jun 2009 11:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1484) Rename base
	package name
In-Reply-To: <17920878.1231877584176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21876548.1244128376651.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1484:
---------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0 Beta)


> Rename base package name
> ------------------------
>
>                 Key: JBMESSAGING-1484
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1484
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.CR1
>
>
> Rename org.jboss.messaging to something else.
> Suggestions are:
> org.jboss.jbm
> ....

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 11:43:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 4 Jun 2009 11:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1638) Ordering
 Group messages delivery is not correctly handled after XA prepare()
Message-ID: <19894567.1244130236527.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ordering Group messages delivery is not correctly handled after XA prepare() 
-----------------------------------------------------------------------------

                 Key: JBMESSAGING-1638
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1638
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.4.GA, 1.4.0.SP3.CP08
            Reporter: Howard Gao
            Assignee: Howard Gao
             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA



In XA environment, if one ordering group message is received within a transaction but not committed, the next message can't be received. The problem is that after the transaction is prepared, the next message is delivered, thus broken the ordering.





-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 11:45:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 4 Jun 2009 11:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1638) Ordering
 Group messages delivery is not correctly handled after XA prepare()
In-Reply-To: <19894567.1244130236527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5289374.1244130356634.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao updated JBMESSAGING-1638:
------------------------------------

    Description: 

In XA environment, if one ordering group message is received within a transaction but not committed, the next message can't be received. The problem is that after the transaction is prepared, the next message is delivered, thus breaking the ordering.





  was:

In XA environment, if one ordering group message is received within a transaction but not committed, the next message can't be received. The problem is that after the transaction is prepared, the next message is delivered, thus broken the ordering.







> Ordering Group messages delivery is not correctly handled after XA prepare() 
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1638
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1638
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In XA environment, if one ordering group message is received within a transaction but not committed, the next message can't be received. The problem is that after the transaction is prepared, the next message is delivered, thus breaking the ordering.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 12:18:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 4 Jun 2009 12:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-140) Define javac target
 for build consistency
In-Reply-To: <3295821.1244048854856.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9761296.1244132336891.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-140:
-------------------------------

    Fix Version/s: JBossWeb-2.0.0.GA_CP11


> Define javac target for build consistency
> -----------------------------------------
>
>                 Key: JBWEB-140
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-140
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Mike Millson
>             Fix For: JBossWeb-2.0.0.GA_CP11
>
>         Attachments: build.xml.patch
>
>
> Currently the build will target the JVM version being used to run the ant build task. Add the ability to build with JDK 1.6 by specifying the javac target to 1.5.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 12:22:56 2009
From: jira-events at lists.jboss.org (Nick Boldt (JIRA))
Date: Thu, 4 Jun 2009 12:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2112) Cannot build
 Drools IDE w/ OpenJDK 6 (vm crashes)
Message-ID: <4361993.1244132576401.JavaMail.jira@cloud.prod.atl2.jboss.com>

Cannot build Drools IDE w/ OpenJDK 6 (vm crashes)
-------------------------------------------------

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


Drools 5.0.x can compile with OpenJDK6; Drools 5.1 cannot. See attached logs. 

This prevents the JBoss Tools build from being able to run locally on Fedora w/ the out-of-box JVM (Open JDK 6).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 12:24:56 2009
From: jira-events at lists.jboss.org (Nick Boldt (JIRA))
Date: Thu, 4 Jun 2009 12:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2112) Cannot build
 Drools IDE w/ OpenJDK 6 (vm crashes)
In-Reply-To: <4361993.1244132576401.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24714234.1244132696587.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Nick Boldt updated JBRULES-2112:
--------------------------------

    Attachment: hs_err_pid29622.log
                build.log.20090604-0200.txt


Attached are the build log (see line 425) and the referenced hs_err_pid*.log file.

> Cannot build Drools IDE w/ OpenJDK 6 (vm crashes)
> -------------------------------------------------
>
>                 Key: JBRULES-2112
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2112
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Nick Boldt
>            Assignee: Mark Proctor
>         Attachments: build.log.20090604-0200.txt, hs_err_pid29622.log
>
>
> Drools 5.0.x can compile with OpenJDK6; Drools 5.1 cannot. See attached logs. 
> This prevents the JBoss Tools build from being able to run locally on Fedora w/ the out-of-box JVM (Open JDK 6).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 12:24:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 4 Jun 2009 12:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBWEB-140) Define javac target
 for build consistency
In-Reply-To: <3295821.1244048854856.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8814232.1244132696463.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson resolved JBWEB-140.
--------------------------------

    Resolution: Done


> Define javac target for build consistency
> -----------------------------------------
>
>                 Key: JBWEB-140
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-140
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Mike Millson
>             Fix For: JBossWeb-2.0.0.GA_CP11
>
>         Attachments: build.xml.patch
>
>
> Currently the build will target the JVM version being used to run the ant build task. Add the ability to build with JDK 1.6 by specifying the javac target to 1.5.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 12:31:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 4 Jun 2009 12:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1639) Validate
 configuration values programmatically
Message-ID: <9257056.1244133116418.JavaMail.jira@cloud.prod.atl2.jboss.com>

Validate configuration values programmatically
----------------------------------------------

                 Key: JBMESSAGING-1639
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1639
             Project: JBoss Messaging
          Issue Type: Feature Request
          Components: Configuration and Management
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 2.0.0.CR1


using XSD to validate configuration values make the schema more complex and error-prone (the error messages are hard to understand too).

We should move to programmatic validation. E.g. in FileConfiguration, when we read the values from the configuration, we could add a validation step to check values (e.g. must be -1 or > 0 which is impossible to express in a XML Schema)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 12:43:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 4 Jun 2009 12:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-89) Make the Server
 start message look more like the legacy
Message-ID: <26051330.1244133836509.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make the Server start message look more like the legacy
-------------------------------------------------------

                 Key: JBBOOT-89
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-89
             Project: JBoss Bootstrap
          Issue Type: Feature Request
          Components: impl-base
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger


(12:17:53 PM) bstansberry: ALR: request you make "Started: org.jboss.bootstrap.impl.as.server.JBossASServerImpl at bc92535 in 1m:3s:597ms" read more like the old msg. Something easy to search for in server.log
(12:18:28 PM) bstansberry: I used to search for "Started in"; in AS 4 for "MicroKernel"
(12:18:31 PM) ALR: bstansberry: k.  https://jira.jboss.org/jira/browse/JBBOOT-83

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 12:55:57 2009
From: jira-events at lists.jboss.org (Mike Lewis (JIRA))
Date: Thu, 4 Jun 2009 12:55:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-733) runtime
 instrumentation classloading can't find class for array of bytes [B
Message-ID: <6914195.1244134557165.JavaMail.jira@cloud.prod.atl2.jboss.com>

runtime instrumentation classloading can't find class for array of bytes [B
---------------------------------------------------------------------------

                 Key: JBAOP-733
                 URL: https://jira.jboss.org/jira/browse/JBAOP-733
             Project: JBoss AOP
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.1.GA
         Environment: OS: 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux
Java: Java(TM) SE Runtime Environment (build 1.6.0_10-b33) 
JBoss AS: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221053)
            Reporter: Mike Lewis


Our app has conf/bootstrap/aop.xml configured with:
 
enableLoadTimeWeaving = true
optimized = false
instrumentor = org.jboss.aop.instrument.ClassicInstrumentor

Our class TLSByteArrayOutputStream has a field tagged for the ThreadBased aspect:

@Threadbased protected byte[] buffer;

Our .aop archive has META-INF/jboss-aop.xml with:









-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 13:19:08 2009
From: jira-events at lists.jboss.org (Mike Lewis (JIRA))
Date: Thu, 4 Jun 2009 13:19:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-733) runtime
 instrumentation classloading can't find class for array of bytes [B
In-Reply-To: <6914195.1244134557165.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31163484.1244135948659.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Lewis updated JBAOP-733:
-----------------------------

    Description: 
Our app has conf/bootstrap/aop.xml configured with:
 
enableLoadTimeWeaving = true
optimized = false
verbose = true
instrumentor = org.jboss.aop.instrument.ClassicInstrumentor

Our class TLSByteArrayOutputStream has a field tagged for the ThreadBased aspect:

@Threadbased protected byte[] buffer;

Our .aop archive has META-INF/jboss-aop.xml with:

<aspect class="org.jboss.aspects.ThreadbasedAspect" scope="PER_JOINPOINT"/>
<bind pointcut="field(* *->@org.jboss.aspects.Threadbased)">
  <advice name="access" aspect="org.jboss.aspects.ThreadbasedAspect"/>
</bind>

The error on the console during startup:

10:01:28,708 ERROR [STDERR] javassist.CannotCompileException: by javassist.bytecode.BadBytecode: cannot find [B
10:01:28,708 ERROR [STDERR] 	at javassist.CtBehavior.setBody(CtBehavior.java:370)
10:01:28,708 ERROR [STDERR] 	at javassist.CtBehavior.setBody(CtBehavior.java:334)
10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.NonOptimizedFieldAccessTransformer.buildWrappers(NonOptimizedFieldAccessTransformer.java:119)
10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.NonOptimizedFieldAccessTransformer.doBuildFieldWrappers(NonOptimizedFieldAccessTransformer.java:102)
10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.FieldAccessTransformer.buildFieldWrappers(FieldAccessTransformer.java:103)
10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:778)
10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.ClassicWeavingStrategy.translate(ClassicWeavingStrategy.java:110)
10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.AspectManager.translate(AspectManager.java:1071)
10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.AspectManager.transform(AspectManager.java:1015)
10:01:28,709 ERROR [STDERR] 	at org.jboss.aop.standalone.AOPTransformer.aspectTransform(AOPTransformer.java:87)
10:01:28,709 ERROR [STDERR] 	at org.jboss.aop.standalone.AOPTransformer.transform(AOPTransformer.java:75)
10:01:28,709 ERROR [STDERR] 	at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
10:01:28,709 ERROR [STDERR] 	at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.defineClass1(Native Method)
10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
10:01:28,709 ERROR [STDERR] 	at java.security.AccessController.doPrivileged(Native Method)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
10:01:28,709 ERROR [STDERR] 	at com.company.framework.CoreSystem.getSystemProperty(CoreSystem.java:699)
10:01:28,709 ERROR [STDERR] 	at com.company.framework.impl.CoreServlet.init(CoreServlet.java:81)
10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1048)
10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:950)
10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4122)
10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4421)
10:01:28,709 ERROR [STDERR] 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
10:01:28,709 ERROR [STDERR] 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
10:01:28,709 ERROR [STDERR] 	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
10:01:28,710 ERROR [STDERR] 	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
10:01:28,710 ERROR [STDERR] 	at org.jboss.web.deployers.WebModule.start(WebModule.java:97)
10:01:28,710 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10:01:28,710 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
10:01:28,710 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
10:01:28,710 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
10:01:28,710 ERROR [STDERR] 	at $Proxy38.start(Unknown Source)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.ServiceController.start(ServiceController.java:460)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
10:01:28,710 ERROR [STDERR] 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
10:01:28,710 ERROR [STDERR] 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
10:01:28,711 ERROR [STDERR] 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
10:01:28,711 ERROR [STDERR] 	at org.jboss.Main.boot(Main.java:221)
10:01:28,711 ERROR [STDERR] 	at org.jboss.Main$1.run(Main.java:556)
10:01:28,711 ERROR [STDERR] 	at java.lang.Thread.run(Thread.java:619)
10:01:28,712 ERROR [STDERR] Caused by: javassist.bytecode.BadBytecode: cannot find [B
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.TypeData$TypeName.update(TypeData.java:282)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.TypeData$TypeName.setType(TypeData.java:203)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.TypeData.setType(TypeData.java:46)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:908)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:898)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:898)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:813)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:615)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:101)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:161)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:171)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:120)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:96)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:404)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:389)
10:01:28,712 ERROR [STDERR] 	at javassist.CtBehavior.setBody(CtBehavior.java:364)
10:01:28,712 ERROR [STDERR] 	... 105 more
10:01:28,712 ERROR [ClassicWeavingStrategy] java.lang.RuntimeException: failed to transform: com.company.rtl.io.TLSByteArrayOutputStream

with org.jboss logging set to trace, the following logs are produced:

2009-06-04 09:17:50,401 DEBUG [org.jboss.aop.instrument.JoinpointSimpleClassifier] (main) com.company.rtl.io.TLSByteArrayOutputStream.buffer:[B matches pointcut: field(* *->@org.jboss.aspects.Threadbased)
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] initiating get of [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] looking for [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] looking for [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] checking parent first for [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking parent (parentFirst)
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking parent (parentFirst)
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking parent (parentFirst)
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from pool parent - no parent pool
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking cache
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at b3e6577 org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 searching just this pool for [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 checking local cache for [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at b3e6577 org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 found [B in poolnull
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - creating
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 attempting to create [B in parent pool (parentFirst)
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 created [B null
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking cache
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 1d7b51e8 org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 searching just this pool for [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 checking local cache for [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 1d7b51e8 org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 found [B in poolnull
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - creating
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 attempting to create [B in parent pool (parentFirst)
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 attempting to create [B in parent pool (parentFirst)
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 created [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 created [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking cache
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 68d39f3c org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 searching just this pool for [B
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 checking local cache for [B
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 68d39f3c org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 found [B in poolnull
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - creating
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 attempting to create [B in parent pool (parentFirst)
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 attempting to create [B in parent pool (parentFirst)
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 attempting to create [B in parent pool (parentFirst)
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 created [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 created [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 created [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1526730988 [class path: BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1526730988 [class path: BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 539342413 [class path: BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 539342413 [class path: BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1931573327 [class path: BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1931573327 [class path: BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 544899859 [class path: BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml}:] - dcl:BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,853 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 544899859 [class path: BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml}:] - dcl:BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,853 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1959325602 [class path: BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/}:] - dcl:BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1959325602 [class path: BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/}:] - dcl:BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 713962167 [class path: BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/}:] - dcl:BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 713962167 [class path: BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/}:] - dcl:BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 333633399 [class path: BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/}:] - dcl:BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 333633399 [class path: BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/}:] - dcl:BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1523167932 [class path: BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/}:] - dcl:BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1523167932 [class path: BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/}:] - dcl:BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 2115856113 [class path: BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/}:] - dcl:BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 2115856113 [class path: BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/}:] - dcl:BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1129291007 [class path: BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/}:] - dcl:BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1129291007 [class path: BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/}:] - dcl:BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1614726683 [class path: BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/}:] - dcl:BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1614726683 [class path: BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/}:] - dcl:BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] found [B in null
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] get cached or create [B from pool parent - no parent pool
2009-06-04 09:17:50,883 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,883 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,883 ERROR [STDERR] (main) javassist.CannotCompileException: by javassist.bytecode.BadBytecode: cannot find [B
2009-06-04 09:17:50,928 ERROR [STDERR] (main) Caused by: javassist.bytecode.BadBytecode: cannot find [B

The same app hosted by jboss-5.0.1.GA doesn't have this problem nor does compiling with AopC.


  was:
Our app has conf/bootstrap/aop.xml configured with:
 
enableLoadTimeWeaving = true
optimized = false
instrumentor = org.jboss.aop.instrument.ClassicInstrumentor

Our class TLSByteArrayOutputStream has a field tagged for the ThreadBased aspect:

@Threadbased protected byte[] buffer;

Our .aop archive has META-INF/jboss-aop.xml with:











> runtime instrumentation classloading can't find class for array of bytes [B
> ---------------------------------------------------------------------------
>
>                 Key: JBAOP-733
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-733
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>         Environment: OS: 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux
> Java: Java(TM) SE Runtime Environment (build 1.6.0_10-b33) 
> JBoss AS: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221053)
>            Reporter: Mike Lewis
>
> Our app has conf/bootstrap/aop.xml configured with:
>  
> enableLoadTimeWeaving = true
> optimized = false
> verbose = true
> instrumentor = org.jboss.aop.instrument.ClassicInstrumentor
> Our class TLSByteArrayOutputStream has a field tagged for the ThreadBased aspect:
> @Threadbased protected byte[] buffer;
> Our .aop archive has META-INF/jboss-aop.xml with:
> <aspect class="org.jboss.aspects.ThreadbasedAspect" scope="PER_JOINPOINT"/>
> <bind pointcut="field(* *->@org.jboss.aspects.Threadbased)">
>   <advice name="access" aspect="org.jboss.aspects.ThreadbasedAspect"/>
> </bind>
> The error on the console during startup:
> 10:01:28,708 ERROR [STDERR] javassist.CannotCompileException: by javassist.bytecode.BadBytecode: cannot find [B
> 10:01:28,708 ERROR [STDERR] 	at javassist.CtBehavior.setBody(CtBehavior.java:370)
> 10:01:28,708 ERROR [STDERR] 	at javassist.CtBehavior.setBody(CtBehavior.java:334)
> 10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.NonOptimizedFieldAccessTransformer.buildWrappers(NonOptimizedFieldAccessTransformer.java:119)
> 10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.NonOptimizedFieldAccessTransformer.doBuildFieldWrappers(NonOptimizedFieldAccessTransformer.java:102)
> 10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.FieldAccessTransformer.buildFieldWrappers(FieldAccessTransformer.java:103)
> 10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:778)
> 10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.ClassicWeavingStrategy.translate(ClassicWeavingStrategy.java:110)
> 10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.AspectManager.translate(AspectManager.java:1071)
> 10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.AspectManager.transform(AspectManager.java:1015)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.aop.standalone.AOPTransformer.aspectTransform(AOPTransformer.java:87)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.aop.standalone.AOPTransformer.transform(AOPTransformer.java:75)
> 10:01:28,709 ERROR [STDERR] 	at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
> 10:01:28,709 ERROR [STDERR] 	at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
> 10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.defineClass1(Native Method)
> 10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
> 10:01:28,709 ERROR [STDERR] 	at java.security.AccessController.doPrivileged(Native Method)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
> 10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> 10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> 10:01:28,709 ERROR [STDERR] 	at com.company.framework.CoreSystem.getSystemProperty(CoreSystem.java:699)
> 10:01:28,709 ERROR [STDERR] 	at com.company.framework.impl.CoreServlet.init(CoreServlet.java:81)
> 10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1048)
> 10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:950)
> 10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4122)
> 10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4421)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.web.deployers.WebModule.start(WebModule.java:97)
> 10:01:28,710 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:01:28,710 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 10:01:28,710 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 10:01:28,710 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
> 10:01:28,710 ERROR [STDERR] 	at $Proxy38.start(Unknown Source)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.ServiceController.start(ServiceController.java:460)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.Main.boot(Main.java:221)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.Main$1.run(Main.java:556)
> 10:01:28,711 ERROR [STDERR] 	at java.lang.Thread.run(Thread.java:619)
> 10:01:28,712 ERROR [STDERR] Caused by: javassist.bytecode.BadBytecode: cannot find [B
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.TypeData$TypeName.update(TypeData.java:282)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.TypeData$TypeName.setType(TypeData.java:203)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.TypeData.setType(TypeData.java:46)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:908)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:898)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:898)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:813)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:615)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:101)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:161)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:171)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:120)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:96)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:404)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:389)
> 10:01:28,712 ERROR [STDERR] 	at javassist.CtBehavior.setBody(CtBehavior.java:364)
> 10:01:28,712 ERROR [STDERR] 	... 105 more
> 10:01:28,712 ERROR [ClassicWeavingStrategy] java.lang.RuntimeException: failed to transform: com.company.rtl.io.TLSByteArrayOutputStream
> with org.jboss logging set to trace, the following logs are produced:
> 2009-06-04 09:17:50,401 DEBUG [org.jboss.aop.instrument.JoinpointSimpleClassifier] (main) com.company.rtl.io.TLSByteArrayOutputStream.buffer:[B matches pointcut: field(* *->@org.jboss.aspects.Threadbased)
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] initiating get of [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] looking for [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] looking for [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] checking parent first for [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking parent (parentFirst)
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking parent (parentFirst)
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking parent (parentFirst)
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from pool parent - no parent pool
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking cache
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at b3e6577 org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 searching just this pool for [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 checking local cache for [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at b3e6577 org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 found [B in poolnull
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - creating
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 attempting to create [B in parent pool (parentFirst)
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 created [B null
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking cache
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 1d7b51e8 org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 searching just this pool for [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 checking local cache for [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 1d7b51e8 org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 found [B in poolnull
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - creating
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 attempting to create [B in parent pool (parentFirst)
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 attempting to create [B in parent pool (parentFirst)
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 created [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 created [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking cache
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 68d39f3c org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 searching just this pool for [B
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 checking local cache for [B
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 68d39f3c org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 found [B in poolnull
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - creating
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 attempting to create [B in parent pool (parentFirst)
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 attempting to create [B in parent pool (parentFirst)
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 attempting to create [B in parent pool (parentFirst)
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 created [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 created [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 created [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1526730988 [class path: BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1526730988 [class path: BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 539342413 [class path: BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 539342413 [class path: BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1931573327 [class path: BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1931573327 [class path: BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 544899859 [class path: BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml}:] - dcl:BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,853 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 544899859 [class path: BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml}:] - dcl:BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,853 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1959325602 [class path: BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/}:] - dcl:BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1959325602 [class path: BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/}:] - dcl:BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 713962167 [class path: BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/}:] - dcl:BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 713962167 [class path: BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/}:] - dcl:BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 333633399 [class path: BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/}:] - dcl:BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 333633399 [class path: BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/}:] - dcl:BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1523167932 [class path: BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/}:] - dcl:BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1523167932 [class path: BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/}:] - dcl:BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 2115856113 [class path: BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/}:] - dcl:BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 2115856113 [class path: BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/}:] - dcl:BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1129291007 [class path: BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/}:] - dcl:BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1129291007 [class path: BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/}:] - dcl:BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1614726683 [class path: BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/}:] - dcl:BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1614726683 [class path: BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/}:] - dcl:BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] found [B in null
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] get cached or create [B from pool parent - no parent pool
> 2009-06-04 09:17:50,883 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,883 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,883 ERROR [STDERR] (main) javassist.CannotCompileException: by javassist.bytecode.BadBytecode: cannot find [B
> 2009-06-04 09:17:50,928 ERROR [STDERR] (main) Caused by: javassist.bytecode.BadBytecode: cannot find [B
> The same app hosted by jboss-5.0.1.GA doesn't have this problem nor does compiling with AopC.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 13:24:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 4 Jun 2009 13:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-127) Release JBoss
 Identity Federation Stack 1.0.0.alpha3
Message-ID: <14162180.1244136296332.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release JBoss Identity Federation Stack 1.0.0.alpha3
----------------------------------------------------

                 Key: JBID-127
                 URL: https://jira.jboss.org/jira/browse/JBID-127
             Project: JBoss Identity
          Issue Type: Task
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.alpha3




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 15:42:08 2009
From: jira-events at lists.jboss.org (Praveen Palaniswamy (JIRA))
Date: Thu, 4 Jun 2009 15:42:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6011) Comments on
 Installation and Getting Started Guide
In-Reply-To: <26862617.1222830261125.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21179206.1244144528223.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Praveen Palaniswamy commented on JBAS-6011:
-------------------------------------------

There are two binary distributions available: 
jboss-5.0.0.CR2.zip 
jboss-5.0.0.CR2-jdk6.zip 


Whats the main differences with them or add info on which flavor to choose and why

> Comments on Installation and Getting Started Guide 
> ---------------------------------------------------
>
>                 Key: JBAS-6011
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6011
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Docs/Installation and Getting Started Guide
>    Affects Versions: JBossAS-5.0.0.CR2
>            Reporter: Shelly McGowan
>            Assignee: Samson Kittoli
>
> Section 1.1 PreRequisites
> The wiki reference:
> Refer to http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossOperatingSystemSpecificIssues 
> refers to issues with Linux 2.6 kernels and installation of JBoss AS 3.x on a MainFrame.
> This reference should be removed.  
> Section 1.1.1 Hardware and Operating System Requirements
> This section refers to "supported" OS/JVM/DB combinations.  There is no support offered for the community release.
> Section 1.1.2:  Configuring your Java Environment
> Both JDK5 and JDK6 can be used with JBoss AS 5.  Please add JDK 6 to this section. 
> Chapter 2 - Installation Alternatives
> Binary Files Download
> ADD
> (extracted from release notes) JBossAS 5.0.0  can be compiled with both Java5 & Java6. The Java5 compiled binary is our primary/recommended binary 
> distribution. It has undergone rigorous testing and can run under both a Java 5 and a Java 6 runtime. When running 
> under Java 6 you need to manually copy the following libraries from the JBOSS_HOME/client directory to the 
> JBOSS_HOME/lib/endorsed directory, so that the JAX-WS 2.0 apis supported by JBossWS are used:
>     * jbossws-native-saaj.jar
>     * jbossws-native-jaxrpc.jar
>     * jbossws-native-jaxws.jar
>     * jbossws-native-jaxws-ext.jar
> The other option is to download the jdk6 distribution (jboss-5.0.0.CR2-jdk6.zip) in which case no configuration 
> changes are required.   
> Refer to the release notes for additional information about running with JDK 6.
> Correct the following:
> "Four types of server configurations will be included in your installation -  minimal  ,  default  , and  all  . The Getting Started Guide explains in detail the different server configuration file sets." to refer to only Three server configurations.  Instead of the reference to the Getting Started Guide (this guide), refer to the section that discusses this topic.
> Section 3.1 Download and Installation
> Replace references to jboss-4.2.2 to jboss-5.0.0
> There are two binary distributions available:
> jboss-5.0.0.CR2.zip
> jboss-5.0.0.CR2-jdk6.zip
> Source File Download
> ANT and mvn are  included with the JBoss distribution in <installdir>/tools/ so the downloading this section of ANT should be removed.
> 4.3 Building with Ant
> [from release notes: If you are building JBossAS from source you'll notice we are migrating to a maven2 build. At this point the build is 
> a hybrid one because it declares all JBoss dependencies as maven2 artifacts, however after the dependencies are 
> resolved/imported the legacy ant based build is used to compile and build the distribution. This will change to a 
> full maven build at some point in time. The jboss maven repo can be found here. Starting from AS5 CR2, please note 
> how the -sources.jar are also downloaded.] Revisit this section for GA for any build changes.
> Add note: When JBossAS 5 is compiled with Java 6, support for the extended JDBC 4 API is included in the binary, however 
> this can only be used under a Java 6 runtime. 
> Correct the following:
>  The JBoss Application Server files are built under the build/jboss-5.0.0.<release> directory 
> they are built under:
> build/output/jboss-5.0.0.<release>
> Chapter 7 - Check your Installation
> Correct the following:
>  To test your installation, move to JBOSS_DIST/jboss-as/bin
> to
> move to JBOSS_DIST/jboss-5.0.0.<release>/bin
> Remove the NOTE that there is no "Server Started" message.  That only pertains to the production config distributed with EAP.
> Update or remove the reference to refer to "Refer to the Getting Started Guide" to the section that discusses the server layout.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 16:15:08 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 4 Jun 2009 16:15:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-90) Add
 @ManagementProperty.readOnly
 annotations for all new properties of JBossASServerConfig
Message-ID: <3923544.1244146508610.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add @ManagementProperty.readOnly annotations for all new properties of JBossASServerConfig
------------------------------------------------------------------------------------------

                 Key: JBBOOT-90
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-90
             Project: JBoss Bootstrap
          Issue Type: Feature Request
          Components: impl-as
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger


Will be available to be exposed/read by JON/consoles

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 16:23:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 4 Jun 2009 16:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-95) JCA/SJC
Message-ID: <10386832.1244147036462.JavaMail.jira@cloud.prod.atl2.jboss.com>

JCA/SJC
-------

                 Key: JBJCA-95
                 URL: https://jira.jboss.org/jira/browse/JBJCA-95
             Project: JBoss JCA
          Issue Type: Task
          Components: Core
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha1


A simple container.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 16:35:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 4 Jun 2009 16:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2111) In-Pattern
 RestrictionConnectiveDescrs (&& and ||) do not support bindings and
 restrictions at the same time
In-Reply-To: <27444468.1244126997455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20759189.1244147756791.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli closed JBRULES-2111.
----------------------------------

    Resolution: Done


Fixed.

> In-Pattern RestrictionConnectiveDescrs (&& and ||) do not support bindings and restrictions at the same time
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2111
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2111
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.0.0.M3,  5.0.0.M4, 5.0.0.M5, 5.0.0.CR1, 5.0.0.FINAL, 5.0.1.FINAL
>         Environment: any
>            Reporter: Davide Sottara
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.1.0.M1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> when trying to use connectives with restrictions and bindings, as in :
>        Type( $f1: field1 op1 expr1 && $f2 : field2 op2 expr2)
> the fieldRestrictions are ignored by the parser and only the bindings are retained.
> Thus, reading the values of $f1 or $f2 returns the right value, but the restrictions
> (field op expr) are not generated

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 17:02:56 2009
From: jira-events at lists.jboss.org (wallace njoroge (JIRA))
Date: Thu, 4 Jun 2009 17:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7000) issues when starting
 jboss server using Linux centos 5.3
In-Reply-To: <6401897.1244067776524.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22768383.1244149376617.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

wallace njoroge closed JBAS-7000.
---------------------------------

    Fix Version/s: JBossAS-5.1.0.GA
       Resolution: Done


This was a user error.  I followed the instructions below and built JBoss using src and it ended up working.

http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Installation_And_Getting_Started_Guide/5/html/source_installation.html


Thanks.

> issues when starting jboss server using Linux centos 5.3
> --------------------------------------------------------
>
>                 Key: JBAS-7000
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7000
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX/Web Console
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: wallace njoroge
>            Assignee: Darran Lofthouse
>             Fix For: JBossAS-5.1.0.GA
>
>
> Environment:
> Centos 5.3  running in VM
> Linux  2.6.18-128.1.10.el5 #1 i686 i686 i386 GNU/Linux
> java version "1.6.0_13"
> Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
> Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)
> Steps.
> 1. $ pwd
> /usr/local/jboss/bin
> 2. run.sh 
> pdadmin at PDPERFAppLnx01 bin]$ ./run.sh
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /usr/local/jboss
>   JAVA: /home/centosadmin/jdk1.6.0_13/bin/java
>   JAVA_OPTS: -Dprogram.name=run.sh -server -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true
>   CLASSPATH: /usr/local/jboss/bin/run.jar:/home/centosadmin/jdk1.6.0_13/lib/tools.jar
> =========================================================================
> 15:14:42,090 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 15:14:42,091 INFO  [ServerImpl] Release ID: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)
> 15:14:42,092 INFO  [ServerImpl] Bootstrap URL: null
> 15:14:42,092 INFO  [ServerImpl] Home Dir: /usr/local/jboss
> 15:14:42,092 INFO  [ServerImpl] Home URL: file:/usr/local/jboss/
> 15:14:42,092 INFO  [ServerImpl] Library URL: file:/usr/local/jboss/lib/
> 15:14:42,093 INFO  [ServerImpl] Patch URL: null
> 15:14:42,093 INFO  [ServerImpl] Common Base URL: file:/usr/local/jboss/common/
> 15:14:42,094 INFO  [ServerImpl] Common Library URL: file:/usr/local/jboss/common/lib/
> 15:14:42,094 INFO  [ServerImpl] Server Name: default
> 15:14:42,094 INFO  [ServerImpl] Server Base Dir: /usr/local/jboss/server
> 15:14:42,094 INFO  [ServerImpl] Server Base URL: file:/usr/local/jboss/server/
> 15:14:42,095 INFO  [ServerImpl] Server Config URL: file:/usr/local/jboss/server/default/conf/
> 15:14:42,095 INFO  [ServerImpl] Server Home Dir: /usr/local/jboss/server/default
> 15:14:42,095 INFO  [ServerImpl] Server Home URL: file:/usr/local/jboss/server/default/
> 15:14:42,095 INFO  [ServerImpl] Server Data Dir: /usr/local/jboss/server/default/data
> 15:14:42,096 INFO  [ServerImpl] Server Library URL: file:/usr/local/jboss/server/default/lib/
> 15:14:42,096 INFO  [ServerImpl] Server Log Dir: /usr/local/jboss/server/default/log
> 15:14:42,096 INFO  [ServerImpl] Server Native Dir: /usr/local/jboss/server/default/tmp/native
> 15:14:42,096 INFO  [ServerImpl] Server Temp Dir: /usr/local/jboss/server/default/tmp
> 15:14:42,097 INFO  [ServerImpl] Server Temp Deploy Dir: /usr/local/jboss/server/default/tmp/deploy
> 15:14:42,975 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/usr/local/jboss/server/default/conf/bootstrap.xml
> 15:14:43,586 INFO  [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.plugins.cache.CombinedVFSCache]
> 15:14:43,589 INFO  [VFSCacheFactory] Using VFSCache [CombinedVFSCache[real-cache: null]]
> 15:14:43,940 INFO  [CopyMechanism] VFS temp dir: /usr/local/jboss/server/default/tmp
> 15:14:43,941 INFO  [ZipEntryContext] VFS force nested jars copy-mode is enabled.
> 15:14:45,822 INFO  [ServerInfo] Java version: 1.6.0_13,Sun Microsystems Inc.
> 15:14:45,822 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
> 15:14:45,823 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Server VM 11.3-b02,Sun Microsystems Inc.
> 15:14:45,823 INFO  [ServerInfo] OS-System: Linux 2.6.18-128.1.10.el5,i386
> 15:14:45,824 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/usr/local/jboss/lib/endorsed
> 15:14:45,905 INFO  [JMXKernel] Legacy JMX core initialized
> 15:14:49,308 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 487fb7[domain=default, server=default, name=default]
> 15:14:50,731 ERROR [AbstractKernelController] Error installing to Parse: name=vfsfile:/usr/local/jboss/server/default/conf/jboss-service.xml state=Not Installed mode=Manual requiredState=Parse
> org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfsfile:/usr/local/jboss/server/default/conf/jboss-service.xml
>         at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:362)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:322)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:294)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.deploy(AbstractParsingDeployerWithOutput.java:234)
>         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.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.jbos
> Expected.
> Should work
> Error:
> Error creating managed object for vfsfile:/usr/local/jboss/server/default/conf/jboss-service.xml

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 17:11:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 4 Jun 2009 17:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16982694.1244149916579.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry commented on JBAS-6808:
----------------------------------------

Accessing the HAPartition MOs:

There can be more than one HAPartition deployed in an AS, so we use the partitionName property as the MO's name, i.e.

   @ManagementProperty(use={ViewUse.CONFIGURATION}, description="The partition's name")
   @ManagementObjectID(type="HAPartition")
   public String getPartitionName()
   {
      return this.partitionName;
   }

So, you can't just look up the HAPartition ManagedComponent via some fixed name. Instead, use the ComponentType:

ManagementView mgtView = getManagementView(); 
ComponentType type = new ComponentType("MCBean", "HAPartition");
Set<ManagedComponent> hapartitions = mgtView.getComponentsForType(type);
for (ManagedComponent mc : hapartitions)
{
   System.out.println("Partition name is " + mc.getProperty("partitionName");
}

> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 17:58:56 2009
From: jira-events at lists.jboss.org (Tom Murphy (JIRA))
Date: Thu, 4 Jun 2009 17:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2113) NPE thrown by
 LeftTuple.get() method
Message-ID: <32437267.1244152736613.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE thrown by LeftTuple.get() method
------------------------------------

                 Key: JBRULES-2113
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2113
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.0.CR1
         Environment: FOund in 5.0.0.CR1 - Community version. Windows XP
            Reporter: Tom Murphy
            Assignee: Mark Proctor


the get() method on LeftTuple throws a null exception under certain circumstances, which are as yet undetermined.
Here is the Code:

public InternalFactHandle get(final int index) {
        LeftTuple entry = this;
        while ( entry.index != index ) {
            entry = entry.parent;
        }
        return entry.handle;
    }

Note that the loop moves to each parent in succession, but never checks for entry != null. If it does get to the end of the chain, it will throw an NPE

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 19:20:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 4 Jun 2009 19:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6625) EJB 1.x or 2.x
	metrics
In-Reply-To: <7034128.1237195628874.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8127137.1244157656556.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene commented on JBAS-6625:
---------------------------------------

This has been fully implemented in the EAP5 branch. See the JMXMappingUnitTestCase:

Set<ManagedComponent> comps = mgtView.getComponentsForType(new ComponentType("EJB", "StatefulSession"));
      for (ManagedComponent comp : comps)
      {
         System.out.println(comp.getName());
         ManagedProperty property = comp.getProperty("DetypedInvocationStatistics");
         if ("jboss.j2ee:jndiName=ejb/StatefulCounterEjb,service=EJB".equals(comp.getName()))
         {
            MetaValue value = property.getValue();
            System.out.println("Value = " + value);
            CompositeValue methodStatsMap = (CompositeValue)((CompositeValue) value).get("methodStats");
            CompositeValue methodStats = (CompositeValue)methodStatsMap.get("count");
            assertEquals(2L, ((SimpleValue)methodStats.get("count")).getValue());
            return;
         }
      }

      fail("Could not find EJB!");

> EJB 1.x or 2.x metrics
> ----------------------
>
>                 Key: JBAS-6625
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6625
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB2, Management services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> EJB 1.x or 2.x Stateless Session Bean metrics (in addition to availability)
>            <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=StatelessSessionBean -->
>            <metric displayName="Create Calls"
>                    property="{stats.createCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Remove Calls"
>                    property="{stats.removeCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Method-Ready Beans"
>                    property="{stats.methodReadyCount.current}"
>                    displayType="summary"/>
>            <metric displayName="Pool Size"
>                    property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}CurrentSize}"/>
>            <metric displayName="Max Pool Size"
>                    property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}MaxSize}"/> 
> Plus the complex method invocation metrics 
>  <metric property="stats" dataType="calltime" units="milliseconds"
>                     defaultOn="false" defaultInterval="600000" destinationType="Method Name"
>                     description="the minimum, maximum, and average invocation times for each of the methods exposed by this EJB"/>
> EJB 1.x or 2.x Stateful Session Bean metrics (in addition to avail):
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=StatefulSessionBean -->
>            <metric displayName="Create Calls"
>                    description="Number of creates executed since the last time this EJB's stats were reset"
>                    property="{stats.createCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Remove Calls"
>                    description="Number of removes since the last time this EJB's stats were reset"
>                    property="{stats.removeCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Method-Ready Beans"
>                    description="The count of beans in the method-ready state"
>                    property="{stats.methodReadyCount.current}"
>                    displayType="summary"/>
>            <metric displayName="Passive Beans"
>                    description="The count of beans in the passivated state"
>                    property="{stats.passiveCount.current}"
>                    displayType="summary"/> 
> EJB 1.x or 2.x Entity Bean metrics (in addition to availability)
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=EntityBean -->
>      <metric displayName="Create Calls"
>               property="{stats.createCount.count}"
>               displayType="summary"
>               measurementType="trendsup"/>
>       <metric displayName="Remove Calls"
>               property="{stats.removeCount.count}"
>               displayType="summary"
>               measurementType="trendsup"/>
>       <metric displayName="Method-Ready Beans"
>               property="{stats.methodReadyCount.current}"
>               displayType="summary"/>
>       <metric displayName="Pooled Beans"
>               property="{stats.pooledCount.current}"
>               displayType="summary"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=cache,service=EJB}CacheSize}"
>                displayName="Cache Size"
>                defaultOn="true"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=cache,service=EJB}PassivatedCount}"
>                displayName="Passivated Count"
>                defaultOn="true"
>                measurementType="trendsup"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}PoolSize}"
>                displayName="Current Size"
>                defaultOn="true"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}MaxPoolSize}"
>                displayName="Max Size"
>                defaultOn="true"/>
> EJB 1.x or 2.x Message Driven Bean metrics (in addition to availability)
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=MessageDrivenBean -->
> <metric displayName="Create Calls"
> property="{stats.createCount.count}"
> displayType="summary"
> measurementType="trendsup"/>
> <metric displayName="Remove Calls"
> property="{stats.removeCount.count}"
> displayType="summary"
> measurementType="trendsup"/>
> <metric displayName="Method-Ready Beans"
> property="{stats.messageCount.count}"
> displayType="summary"
>               measurementType="trendsup"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 19:24:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 4 Jun 2009 19:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6625) EJB 1.x or 2.x
	metrics
In-Reply-To: <7034128.1237195628874.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30826944.1244157896566.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene resolved JBAS-6625.
-----------------------------------

    Resolution: Done


Reopen if we are missing something here

> EJB 1.x or 2.x metrics
> ----------------------
>
>                 Key: JBAS-6625
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6625
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB2, Management services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> EJB 1.x or 2.x Stateless Session Bean metrics (in addition to availability)
>            <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=StatelessSessionBean -->
>            <metric displayName="Create Calls"
>                    property="{stats.createCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Remove Calls"
>                    property="{stats.removeCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Method-Ready Beans"
>                    property="{stats.methodReadyCount.current}"
>                    displayType="summary"/>
>            <metric displayName="Pool Size"
>                    property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}CurrentSize}"/>
>            <metric displayName="Max Pool Size"
>                    property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}MaxSize}"/> 
> Plus the complex method invocation metrics 
>  <metric property="stats" dataType="calltime" units="milliseconds"
>                     defaultOn="false" defaultInterval="600000" destinationType="Method Name"
>                     description="the minimum, maximum, and average invocation times for each of the methods exposed by this EJB"/>
> EJB 1.x or 2.x Stateful Session Bean metrics (in addition to avail):
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=StatefulSessionBean -->
>            <metric displayName="Create Calls"
>                    description="Number of creates executed since the last time this EJB's stats were reset"
>                    property="{stats.createCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Remove Calls"
>                    description="Number of removes since the last time this EJB's stats were reset"
>                    property="{stats.removeCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Method-Ready Beans"
>                    description="The count of beans in the method-ready state"
>                    property="{stats.methodReadyCount.current}"
>                    displayType="summary"/>
>            <metric displayName="Passive Beans"
>                    description="The count of beans in the passivated state"
>                    property="{stats.passiveCount.current}"
>                    displayType="summary"/> 
> EJB 1.x or 2.x Entity Bean metrics (in addition to availability)
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=EntityBean -->
>      <metric displayName="Create Calls"
>               property="{stats.createCount.count}"
>               displayType="summary"
>               measurementType="trendsup"/>
>       <metric displayName="Remove Calls"
>               property="{stats.removeCount.count}"
>               displayType="summary"
>               measurementType="trendsup"/>
>       <metric displayName="Method-Ready Beans"
>               property="{stats.methodReadyCount.current}"
>               displayType="summary"/>
>       <metric displayName="Pooled Beans"
>               property="{stats.pooledCount.current}"
>               displayType="summary"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=cache,service=EJB}CacheSize}"
>                displayName="Cache Size"
>                defaultOn="true"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=cache,service=EJB}PassivatedCount}"
>                displayName="Passivated Count"
>                defaultOn="true"
>                measurementType="trendsup"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}PoolSize}"
>                displayName="Current Size"
>                defaultOn="true"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}MaxPoolSize}"
>                displayName="Max Size"
>                defaultOn="true"/>
> EJB 1.x or 2.x Message Driven Bean metrics (in addition to availability)
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=MessageDrivenBean -->
> <metric displayName="Create Calls"
> property="{stats.createCount.count}"
> displayType="summary"
> measurementType="trendsup"/>
> <metric displayName="Remove Calls"
> property="{stats.removeCount.count}"
> displayType="summary"
> measurementType="trendsup"/>
> <metric displayName="Method-Ready Beans"
> property="{stats.messageCount.count}"
> displayType="summary"
>               measurementType="trendsup"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 19:30:56 2009
From: jira-events at lists.jboss.org (Ronn C (JIRA))
Date: Thu, 4 Jun 2009 19:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Admin Join problem
 -GMS flush by coordinator failed
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3258381.1244158256577.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ronn C commented on JGRP-985:
-----------------------------

Hi Vladimir,

No reason why UNICAST was commented out. I was trying different settings. My original problem would have UNICAST entry.

We do implement state in our real application but in the test case I didn't need to.

I agree that it is hard to replicate on 2.8.0alpha3 (compare to 2.6.3) and I did spend a whole afternoon constantly  at it and thought it was fixed. The next morning I turned up to work tried it a few times and it happened again. 

Besides all of that, are you able to confirm that this is an old problem that 2.8.0alpha3 had specifically addressed? and if it has been ported to 2.6.10.merge? We need to deploy to prod very soon and I'm hesitant to use library that is still in alpha version but if it is not a known issue and has not been fixed in 2.6.10.merge then I need to know.

> Admin  Join problem -GMS flush by coordinator failed
> ----------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 19:33:07 2009
From: jira-events at lists.jboss.org (Ronn C (JIRA))
Date: Thu, 4 Jun 2009 19:33:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Admin Join problem
 -GMS flush by coordinator failed
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11758357.1244158387645.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ronn C commented on JGRP-985:
-----------------------------

BTW: I run this test on a linux redhat machine. Have not tried to replicate this on Windows.

> Admin  Join problem -GMS flush by coordinator failed
> ----------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 23:58:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 4 Jun 2009 23:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Work started: (JBPORTAL-2186) Extraction
 of the WSRP component to only rely on JBoss Portlet Container.
In-Reply-To: <31759938.1223021601206.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17727898.1244174336834.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Work on JBPORTAL-2186 started by Chris Laprun.

> Extraction of the WSRP component to only rely on JBoss Portlet Container.
> -------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2186
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2186
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.7.0 CR1 
>            Reporter: Lionel ROSIER
>            Assignee: Chris Laprun
>            Priority: Optional
>
> I need to make remote portlets without  rely on the entire portal application.
> I have one Jboss AS running with my portal, and i have others JBoss AS running with business applications and portlets.
> I would like to have the minimum stuff with portal-wsrp component and portlet container to make it works in my "business" JBoss servers.
> thank you

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 01:17:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 5 Jun 2009 01:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1638) Ordering
 Group messages delivery is not correctly handled after XA prepare()
In-Reply-To: <19894567.1244130236527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17295793.1244179076536.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1638:
-----------------------------------------

The cause of this problem is that in JBM XA processing, the acknowledgement of the messages in XA transactions happens at prepare() stage, not commit() stage. And the ordering group unlocks a message based on acknowledgement. So after prepare, next message will be delivered.



> Ordering Group messages delivery is not correctly handled after XA prepare() 
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1638
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1638
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In XA environment, if one ordering group message is received within a transaction but not committed, the next message can't be received. The problem is that after the transaction is prepared, the next message is delivered, thus breaking the ordering.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 03:00:57 2009
From: jira-events at lists.jboss.org (maruthi pramod (JIRA))
Date: Fri, 5 Jun 2009 03:00:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-352) unable to generate
 process image in jpdl4
Message-ID: <14071258.1244185257421.JavaMail.jira@cloud.prod.atl2.jboss.com>

unable to generate process image in jpdl4
-----------------------------------------

                 Key: GPD-352
                 URL: https://jira.jboss.org/jira/browse/GPD-352
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM jPDL Designer 4.0.0.beta1
         Environment: windows xp
            Reporter: maruthi pramod
            Assignee: Koen Aers


Hi,
I am new to jbpm and we started R & D no jbpm4 beta version currently.i have requirement that i need to show the user by highlight the active state of the process .i am using jpdl4 1.0.0 beta version. but am unable to view or generate the image for process definitions for the new process definations or the for the examples provide by jbpm 4 beta version. and one more thing that i also unable to see the process image in GWT-console also . please provide some help on this issue.


Thanks & regards 
maruthi

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 04:57:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 5 Jun 2009 04:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1845)
 CancelAsyncTestCase is hanging
In-Reply-To: <11422647.1244192276453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6444659.1244192276739.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf updated EJBTHREE-1845:
------------------------------------

    Attachment: org.jboss.ejb3.async.impl.test.cancel.unit.CancelAsyncTaskTestCase-output.txt


> CancelAsyncTestCase is hanging
> ------------------------------
>
>                 Key: EJBTHREE-1845
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1845
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>            Priority: Critical
>         Attachments: org.jboss.ejb3.async.impl.test.cancel.unit.CancelAsyncTaskTestCase-output.txt
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 04:57:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 5 Jun 2009 04:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1845)
 CancelAsyncTestCase is hanging
Message-ID: <11422647.1244192276453.JavaMail.jira@cloud.prod.atl2.jboss.com>

CancelAsyncTestCase is hanging
------------------------------

                 Key: EJBTHREE-1845
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1845
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Carlo de Wolf
            Priority: Critical
         Attachments: org.jboss.ejb3.async.impl.test.cancel.unit.CancelAsyncTaskTestCase-output.txt



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 05:24:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 5 Jun 2009 05:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1844) Retry operations
 after an EJBTransactionRolledbackException
In-Reply-To: <16255062.1244128029237.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21370852.1244193896569.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf updated EJBTHREE-1844:
------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235567


> Retry operations after an EJBTransactionRolledbackException
> -----------------------------------------------------------
>
>                 Key: EJBTHREE-1844
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1844
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: transactions
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>
> By either annotating a bean or its methods, the applicable methods will retry the operation if an EJBTransactionRolledbackException occurs.
> @TransactionRetry(numRetries=4, waitTime=1, waitTimeUnit=TimeUnit.SECONDS)
> numRetries specifies how many times an operation will be tried.
> waitTime specified the amount of time to wait before retrying with the unit of time specified in waitTimeUnit.
> Default is 3 retries and 1000 milliseconds wait time after an EJBTransactionRolledbackException.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 05:45:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 5 Jun 2009 05:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1841) Improve logging
 for InterceptorsFactory warning
In-Reply-To: <17265944.1243955516468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25916363.1244195156538.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai reassigned EJBTHREE-1841:
--------------------------------------

    Assignee: jaikiran pai


> Improve logging for InterceptorsFactory warning
> -----------------------------------------------
>
>                 Key: EJBTHREE-1841
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1841
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: AS 5.0.0.CR1
>         Environment: Windows XP 32-bit, JBoss AS 5.1.0GA
>            Reporter: Ben Abernathy
>            Assignee: jaikiran pai
>
> Every time this section of code is called, the following warning is displayed:
> 09:02:34,655 WARN  [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
> Upon inspecting EJBTHREE-1246, it appears this warning can be ignored by bean developers. If that is the case, is it necessary to fill up the console and log with benign warnings? There can be lots of these if the application is large.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 08:09:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 5 Jun 2009 08:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1640)
 ClientSessionFactory are
 garbage collected while the sessions are used in the integration tests
Message-ID: <21551780.1244203796542.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClientSessionFactory are garbage collected while the sessions are used in the integration tests
-----------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1640
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1640
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Jeff Mesnil
            Assignee: Tim Fox
             Fix For: 2.0.0.CR1


The client session impl does not have a ref on the factory which was used to create it.

In the integration-tests (e.g. ClientConsumerCloseTest),  there are a lot of:

protected void setUp() throws Exception
{
   ClientSessionFactory sf = new ClientSessionFactoryImpl(new TransportConfiguration(InVMConnectorFactory.class.getName()));
   ... 
   session = sf.createSession(false, true, true);
   session.createQueue(address, queue, false);
}

In that case, the sf variable will be GC'ed while the session field is still used which could lead to problems.

The factory *must not* be GC'ed while it still has sessions. To prevent that in all case, we can add a reference to the factory
in the created sessions.

For the integration-tests, we must also ensure that the sf is properly closed by making the sf a field and call close() in the
teardown methods.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 08:12:07 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Fri, 5 Jun 2009 08:12:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2114) Drools hangs with
 deadlock
 after it has initialized a rule (in multithreaded environment)
Message-ID: <30331207.1244203927899.JavaMail.jira@cloud.prod.atl2.jboss.com>

Drools hangs with deadlock after it has initialized a rule (in multithreaded environment)
-----------------------------------------------------------------------------------------

                 Key: JBRULES-2114
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2114
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 4.0.6
            Reporter: Andrey Nechaev
            Assignee: Mark Proctor
            Priority: Critical


Here is a scenario when drools core hangs with a deadlock:
Suppose we heve a rule throwing an exception in the RHS. 
So, if:
1. Thread A updates the Rule Base with the rule 
2. The rule fires (current thread is Thread A)
3. Rule's RHS throws an exception (still having Thread A as current)
4. Thread B tries to update the Rule Base or the Working Memory (for example, the Thread B inserts a fact)
in such a case the Thread B falls into infinite wait() loop.
Here is the test case showing such a behavior:

package com.test;

import java.io.StringReader;

import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.WorkingMemory;
import org.drools.compiler.PackageBuilder;

public class DroolsTest2 {
	private final static String rule = "" + 
	"package test\n" +
	"import com.test.DroolsTest2;\n" +
	"rule test\n" +
		"\twhen\n" +
		"\tthen\n" +
			"\t\tDroolsTest2.fail();" +
	"end";
	
	private static Object sem = new Object();
	private static boolean seed = false;
	
	public static void main(String[] args) throws Exception {
		final RuleBase rb = RuleBaseFactory.newRuleBase();
		final WorkingMemory wm = rb.newStatefulSession();
		new Thread(new Runnable() {
			@Override
			public void run() {
				seed = false;
				PackageBuilder bld = new PackageBuilder();
				try {
					bld.addPackageFromDrl(new StringReader(rule));				
					rb.addPackage(bld.getPackage());
				} catch(Exception e) {					
				} finally {
					synchronized (sem) {
						seed = true;
						sem.notify();
					}
				}
			}
		}).start();
		Thread ins = new Thread(new Runnable() {
			@Override
			public void run() {
				while(!seed) {
					synchronized (sem) {
						try {
							sem.wait();
						} catch (InterruptedException e) {}
					}
				}
				wm.insert(new Object());
			}
		});
		ins.start();
		ins.join();
	}
	
	public static void fail() {
		throw new IllegalStateException("fail!");
	}
}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 08:13:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Fri, 5 Jun 2009 08:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2114) Drools hangs with
 deadlock
 after it has initialized a rule (in multithreaded environment)
In-Reply-To: <30331207.1244203927899.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18843823.1244204036841.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrey Nechaev updated JBRULES-2114:
------------------------------------

    Attachment: patch-AbstractRuleBase


Here is the patch resolving the issue. It adds missed finally{} section in the AbstractRuleBase class.

> Drools hangs with deadlock after it has initialized a rule (in multithreaded environment)
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2114
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2114
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 4.0.6
>            Reporter: Andrey Nechaev
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: patch-AbstractRuleBase
>
>
> Here is a scenario when drools core hangs with a deadlock:
> Suppose we heve a rule throwing an exception in the RHS. 
> So, if:
> 1. Thread A updates the Rule Base with the rule 
> 2. The rule fires (current thread is Thread A)
> 3. Rule's RHS throws an exception (still having Thread A as current)
> 4. Thread B tries to update the Rule Base or the Working Memory (for example, the Thread B inserts a fact)
> in such a case the Thread B falls into infinite wait() loop.
> Here is the test case showing such a behavior:
> package com.test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> public class DroolsTest2 {
> 	private final static String rule = "" + 
> 	"package test\n" +
> 	"import com.test.DroolsTest2;\n" +
> 	"rule test\n" +
> 		"\twhen\n" +
> 		"\tthen\n" +
> 			"\t\tDroolsTest2.fail();" +
> 	"end";
> 	
> 	private static Object sem = new Object();
> 	private static boolean seed = false;
> 	
> 	public static void main(String[] args) throws Exception {
> 		final RuleBase rb = RuleBaseFactory.newRuleBase();
> 		final WorkingMemory wm = rb.newStatefulSession();
> 		new Thread(new Runnable() {
> 			@Override
> 			public void run() {
> 				seed = false;
> 				PackageBuilder bld = new PackageBuilder();
> 				try {
> 					bld.addPackageFromDrl(new StringReader(rule));				
> 					rb.addPackage(bld.getPackage());
> 				} catch(Exception e) {					
> 				} finally {
> 					synchronized (sem) {
> 						seed = true;
> 						sem.notify();
> 					}
> 				}
> 			}
> 		}).start();
> 		Thread ins = new Thread(new Runnable() {
> 			@Override
> 			public void run() {
> 				while(!seed) {
> 					synchronized (sem) {
> 						try {
> 							sem.wait();
> 						} catch (InterruptedException e) {}
> 					}
> 				}
> 				wm.insert(new Object());
> 			}
> 		});
> 		ins.start();
> 		ins.join();
> 	}
> 	
> 	public static void fail() {
> 		throw new IllegalStateException("fail!");
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 08:23:08 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 5 Jun 2009 08:23:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1638) Ordering Group
 messages delivery is not correctly handled after XA prepare()
In-Reply-To: <19894567.1244130236527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3780515.1244204588055.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao closed JBMESSAGING-1638.
-----------------------------------

    Resolution: Done


done.

Moved the ordering group control to the InMemoryCallback.afterCommit().


> Ordering Group messages delivery is not correctly handled after XA prepare() 
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1638
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1638
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In XA environment, if one ordering group message is received within a transaction but not committed, the next message can't be received. The problem is that after the transaction is prepared, the next message is delivered, thus breaking the ordering.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 08:51:21 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 5 Jun 2009 08:51:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1842)
 ClusteredIsLocalInterceptor finds unstarted beans
In-Reply-To: <10481921.1244040566021.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21284551.1244206281556.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry updated EJBTHREE-1842:
---------------------------------------



> ClusteredIsLocalInterceptor finds unstarted beans
> -------------------------------------------------
>
>                 Key: EJBTHREE-1842
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1842
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: interceptors
>    Affects Versions: AS 4.2.2.GA
>            Reporter: Brian Stansberry
>            Assignee: Paul Ferraro
>
> ClusteredIsLocalInterceptor determines whether a bean is available locally by checking the Ejb3Registry. Problem is beans are registered early in the deployment process, before they are started.
> In the related forum thread pawel.wyrwinski reports how this particularly causes problems when an @Depends("jboss.ha:service=HASingletonDeployer,type=Barrier") annotation is used to make a bean act as an HASingleton. The bean is included in the Ejb3Registry on all nodes but is only started on one.
> A logically obvious solution would be to check whether the target container is started before invoking locally. Unfortunately, AFAICT Container and its subclasses do not expose any method to support such a check.
> Pawel reported this against 4.2.2 so that the "Affects Version" I used, but a quick code check leads me to believe it still exists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 09:53:10 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Fri, 5 Jun 2009 09:53:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6720) Make sure that the
 metrics for
 Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as
 ViewUse.STATISTIC
In-Reply-To: <7508166.1238615242987.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25753540.1244209998990.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ondrej ?i?ka updated JBAS-6720:
-------------------------------

    Environment: 
JBoss AS Branch_5_x r86586, embjopr r266

EmbJopr TS: testQueueMetrics

  was:JBoss AS Branch_5_x r86586, embjopr r266



> Make sure that the metrics for Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as ViewUse.STATISTIC
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6720
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6720
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: JBoss AS Branch_5_x r86586, embjopr r266
> EmbJopr TS: testQueueMetrics
>            Reporter: Farah Juma
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Steps to reproduce:
> Create a new Topic or Queue using Embedded Jopr. Send some messages to the Topic or Queue. Navigate to the "Metrics" tab for the resource. The metrics do not get updated to reflect this change. All the values are 0.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Fri Jun  5 10:39:15 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 10:39:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1845)
 CancelAsyncTestCase is hanging
In-Reply-To: <11422647.1244192276453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23588413.1244212755953.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger reassigned EJBTHREE-1845:
---------------------------------------------

    Assignee: Andrew Lee Rubinger


> CancelAsyncTestCase is hanging
> ------------------------------
>
>                 Key: EJBTHREE-1845
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1845
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>         Attachments: org.jboss.ejb3.async.impl.test.cancel.unit.CancelAsyncTaskTestCase-output.txt
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 10:41:26 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 5 Jun 2009 10:41:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-203) add an option to
 validate just
 built SchemaBinding against the XSD in the default schema resolvers
In-Reply-To: <5112439.1243607876650.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18086862.1244212886642.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBXB-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470813#action_12470813 ] 

Alexey Loubyansky commented on JBXB-203:
----------------------------------------

Wiki page about the feature http://www.jboss.org/community/wiki/Bindingvalidation

> add an option to validate just built SchemaBinding against the XSD in the default schema resolvers
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBXB-203
>                 URL: https://jira.jboss.org/jira/browse/JBXB-203
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> There was a suggestion to add an option to validate the consistency of SchemaBinding instances built from JAXB/JBossXB annotations against their corresponding XSDs during schema resolution.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 11:31:36 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 5 Jun 2009 11:31:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-68) JBoss Metadata
	1.0.2.Beta1
In-Reply-To: <29947535.1236869745527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17962750.1244215896716.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jesper Pedersen updated JBJCA-68:
---------------------------------

    Summary: JBoss Metadata 1.0.2.Beta1  (was: JBoss Metadata 1.0.0.CR18)


> JBoss Metadata 1.0.2.Beta1
> --------------------------
>
>                 Key: JBJCA-68
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-68
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha1
>
>
> Standalone + Test

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 11:53:41 2009
From: jira-events at lists.jboss.org (Matthias Lanz (JIRA))
Date: Fri, 5 Jun 2009 11:53:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1844) Retry
 operations after an EJBTransactionRolledbackException
In-Reply-To: <16255062.1244128029237.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6860298.1244217231616.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470830#action_12470830 ] 

Matthias Lanz commented on EJBTHREE-1844:
-----------------------------------------

Hi Carlo,

sounds very good, exactly what I were looking for :-)

I think this new annotation can be applied as default for all SLSB in ejb3-interceptors-aop.xml, that would be very useful.
If it can be applied to all session beans by default it would be neccessary that "numRetries=0" is a valid value, to disable retry for specific beans.

I wonder how nested session bean calls are handled. I assume this annotation can only have any effect on session bean methods that are starting a new transaction, not using one previously started from the caller?

As a extension in the future it would be nice if one could define any kind of retry-handler; an interface which can be implemented to decide on which exceptions a retry should occur.

Example:
@TransactionRetry(numRetries=4, waitTime=1, waitTimeUnit=TimeUnit.SECONDS, retryHandler=MyPersonalOnlyDeadlockRetryHandler.class) 

and then:

public class MyPersonalOnlyDeadlockRetryHandler implements com.jboss.ejb3.RetryHandler {

  public boolean isRetryable(Exception e) {
    return (e instanceof EJBRolledbackException && e.getCause() instanceof MySqlDeadLockDetectedException);
  }


But that is really a nice-to-have, retries on every error should do no harm.



> Retry operations after an EJBTransactionRolledbackException
> -----------------------------------------------------------
>
>                 Key: EJBTHREE-1844
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1844
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: transactions
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>
> By either annotating a bean or its methods, the applicable methods will retry the operation if an EJBTransactionRolledbackException occurs.
> @TransactionRetry(numRetries=4, waitTime=1, waitTimeUnit=TimeUnit.SECONDS)
> numRetries specifies how many times an operation will be tried.
> waitTime specified the amount of time to wait before retrying with the unit of time specified in waitTimeUnit.
> Default is 3 retries and 1000 milliseconds wait time after an EJBTransactionRolledbackException.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 12:23:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 5 Jun 2009 12:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-82) Circle of trust servlet
In-Reply-To: <13620737.1240499860623.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25025382.1244219036422.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed JBID-82.
-----------------------------

    Resolution: Done


> Circle of trust servlet
> -----------------------
>
>                 Key: JBID-82
>                 URL: https://jira.jboss.org/jira/browse/JBID-82
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha2
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha3
>
>
> Circle of Trust servlet  that can be configured to pick up metadata from a set of URLs and update the common store.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 13:39:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 13:39:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-84) Missing ServerConfig
 @ManagedProperty annotations
In-Reply-To: <1654126.1243254896568.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17336346.1244223597180.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger resolved JBBOOT-84.
---------------------------------------

    Resolution: Done


Local tests show these now passing on 2.0.0-SNAPSHOT

> Missing ServerConfig @ManagedProperty annotations
> -------------------------------------------------
>
>                 Key: JBBOOT-84
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-84
>             Project: JBoss Bootstrap
>          Issue Type: Bug
>    Affects Versions: 0.1.2
>            Reporter: Emanuel Muckenhuber
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-alpha-1
>
>
> The BasicJBossASServerConfig is missing @ManagedProperty annotations, which causes those two tests failures: 
> > org.jboss.test.cluster.defaultcfg.profileservice.test.FarmedClusterHotDeployUnitTestCase(ClusteredProfileService).testFarmHotDeployment
> > org.jboss.test.deployers.test.DeploymentManagerUnitTestCase(profileservice).testHotDeploymentBeans 
> I assume that this ServerConfig is the one used previously (which seems to have the correct annotations):
> https://svn.jboss.org/repos/jbossas/projects/bootstrap/tags/jboss-bootstrap-1.0.0-Beta-3/src/main/java/org/jboss/bootstrap/BaseServerConfig.java

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 13:39:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 13:39:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-90) Add
 @ManagementProperty.readOnly
 annotations for all new properties of JBossASServerConfig
In-Reply-To: <3923544.1244146508610.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4509409.1244223597421.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger resolved JBBOOT-90.
---------------------------------------

    Fix Version/s: 2.0.0-alpha-1
       Resolution: Done


> Add @ManagementProperty.readOnly annotations for all new properties of JBossASServerConfig
> ------------------------------------------------------------------------------------------
>
>                 Key: JBBOOT-90
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-90
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-as
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-alpha-1
>
>
> Will be available to be exposed/read by JON/consoles

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 13:43:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 13:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-91) Resolve dependencies
 in preparation for 2.0.0-alpha-1 release
Message-ID: <22684076.1244223836413.JavaMail.jira@cloud.prod.atl2.jboss.com>

Resolve dependencies in preparation for 2.0.0-alpha-1 release
-------------------------------------------------------------

                 Key: JBBOOT-91
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-91
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: build, impl-as, impl-base, impl-mc, spi, spi-as, spi-mc
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 2.0.0-alpha-1


Used to track commits for upgrades in preparation for 2.0.0-alpha-1 release of:

build
spi
spi-mc
spi-as
impl-base
impl-mc
impl-as

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 14:43:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 14:43:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-85) Undeploy
 services/deployments on shutdown of server
In-Reply-To: <14639616.1243256216555.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <421026.1244227437341.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger resolved JBBOOT-85.
---------------------------------------

    Fix Version/s: 2.0.0-alpha-1
       Resolution: Done


> Undeploy services/deployments on shutdown of server
> ---------------------------------------------------
>
>                 Key: JBBOOT-85
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-85
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-as
>    Affects Versions: 0.1.2
>            Reporter: jaikiran pai
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-alpha-1
>
>
> Creating this task based on our email discussion:
> Updated my JBoss AS 5_x branch to see the bootstrap changes (0.1.2 of impl-as). Looks like the way shutdown is handled in AS has now changed? I did a Ctrl+C on the command prompt and the server shutdown "immidiately". In earlier versions, i remember a shutdown would trigger undeployments of various deployments. I don't see this happening anymore. Thought you might be interested in this  :)  Let me know if you need more information. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 14:43:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 14:43:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6974) Ensure the Shutdown
 Hook fully shuts down the Server
In-Reply-To: <20457385.1243304636427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27072829.1244227437110.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger resolved JBAS-6974.
---------------------------------------

    Resolution: Done


> Ensure the Shutdown Hook fully shuts down the Server
> ----------------------------------------------------
>
>                 Key: JBAS-6974
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6974
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: JBAS-6974.patch
>
>
> Shutdown Hook is not calling full shutdown before the process exits.
> For starters, there's this:
> if (currentState.equals(LifecycleState.STARTED) || currentState.equals(LifecycleState.STARTING))
> Find other possible problems and ensure the lifecycle goes through full shutdown before the VM can terminate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 14:43:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 14:43:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-91) Resolve
 dependencies in preparation for 2.0.0-alpha-1 release
In-Reply-To: <22684076.1244223836413.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19771827.1244227437519.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger resolved JBBOOT-91.
---------------------------------------

    Resolution: Done


> Resolve dependencies in preparation for 2.0.0-alpha-1 release
> -------------------------------------------------------------
>
>                 Key: JBBOOT-91
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-91
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: build, impl-as, impl-base, impl-mc, spi, spi-as, spi-mc
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-alpha-1
>
>
> Used to track commits for upgrades in preparation for 2.0.0-alpha-1 release of:
> build
> spi
> spi-mc
> spi-as
> impl-base
> impl-mc
> impl-as

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 15:02:01 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 15:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16626479.1244228521736.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger commented on JBAS-6808:
-------------------------------------------

Now in Branch_5_x (not yet trunk):

+++ ManagedComponent(name=jboss.system:type=ServerConfig, type=(ComponentType{type=MCBean, subtype=ServerConfig}), compName=jboss.system:type=ServerConfig, attachment: org.jboss.bootstrap.impl.as.config.BasicJBossASServerConfig
++++++ properties: [serverHomeDir, serverLogLocation, udpGroup, homeUrl, serverLogDir, serverDataLocation, homeDir, serverLibraryURL, serverDataDir, bindAddress, nativeLibraryLocation, serverName, commonBaseURL, serverHomeURL, bootstrapURL, serverTempDir, serverNativeDir, partitionName, udpPort, commonLibraryURL, serverBaseDir, serverTempLocation, serverConfLocation, bootLibraryLocation, serverBaseURL]


> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 15:03:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Fri, 5 Jun 2009 15:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2115) Changing import /
 globals not considered a change
Message-ID: <12795241.1244228636947.JavaMail.jira@cloud.prod.atl2.jboss.com>

Changing import / globals not considered a change
-------------------------------------------------

                 Key: JBRULES-2115
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2115
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse (flow)
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen
             Fix For: FUTURE


When changing the imports or globals inside the properties dialog for split constraints or the event wait constraint, the editor is not aware of these changes.  As a result, if you only change the imports or globals in your process, the editor will not pick up the change and you won't be able to save the process.

Steps:
1. Create a new rules flow file using the "RuleFlow file" wizard.
2. Add an Event Wait and an End node. Create connections between them.
3. Save the file. Open the rf file in another editor (such as vi). Analyze the structure.
4. From the event wait node's properties, open the constraints -> global section. Add "global String testStr"
5. Try to save the file, which thinks it hasn't changed. Open the rf file in another editor (such as vi). Notice that the global variable is missing from the file.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 16:24:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 16:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-92) Expose partition
 name as a @ManagementProperty
Message-ID: <80513.1244233496440.JavaMail.jira@cloud.prod.atl2.jboss.com>

Expose partition name as a @ManagementProperty
----------------------------------------------

                 Key: JBBOOT-92
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-92
             Project: JBoss Bootstrap
          Issue Type: Feature Request
          Components: legacy
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger


Requested by Brian for inclusion into EAP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 16:24:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 16:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-92) Expose partition
 name as a @ManagementProperty
In-Reply-To: <80513.1244233496440.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17088556.1244233496549.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger updated JBBOOT-92:
--------------------------------------

    Affects Version/s: 1.0.1


> Expose partition name as a @ManagementProperty
> ----------------------------------------------
>
>                 Key: JBBOOT-92
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-92
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: legacy
>    Affects Versions: 1.0.1
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>
> Requested by Brian for inclusion into EAP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 17:02:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 17:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-92) Expose partition
 name as a @ManagementProperty
In-Reply-To: <80513.1244233496440.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16502875.1244235776420.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger resolved JBBOOT-92.
---------------------------------------

    Fix Version/s: 1.0.1
       Resolution: Done


> Expose partition name as a @ManagementProperty
> ----------------------------------------------
>
>                 Key: JBBOOT-92
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-92
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: legacy
>    Affects Versions: 1.0.1
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.0.1
>
>
> Requested by Brian for inclusion into EAP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 17:07:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 17:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13061809.1244236076706.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger commented on JBAS-6808:
-------------------------------------------

For EAP, bring jboss-bootstrap to 1.0.1.  This should bring in JBBOOT-92.  Let me know if there are issues (legacy is much harder to test in place, and I haven't done real due diligence in supporting it as the whole impl is @Deprecated)

> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 17:11:07 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 17:11:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21724466.1244236267599.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger updated JBAS-6808:
--------------------------------------

    Comment: was deleted


> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 17:20:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 5 Jun 2009 17:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-530) Look at using
 refids instead
 of properties to refer to thirdparty jars in the dist build.
In-Reply-To: <13279899.1243637036330.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <189575.1244236856534.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Paul Gier reassigned JBBUILD-530:
---------------------------------

    Assignee: Paul Gier


> Look at using refids instead of properties to refer to thirdparty jars in the dist build.
> -----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-530
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-530
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the AS distribution build uses properties set by the maven ant tasks to access the various thirdparty dependencies.
> It might be better to use refids since this will cause the build to immediately fail when one is expected but not found.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 17:44:07 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 5 Jun 2009 17:44:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-127) Release JBoss Identity
 Federation Stack 1.0.0.alpha3
In-Reply-To: <14162180.1244136296332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25035045.1244238247751.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed JBID-127.
------------------------------

    Resolution: Done


> Release JBoss Identity Federation Stack 1.0.0.alpha3
> ----------------------------------------------------
>
>                 Key: JBID-127
>                 URL: https://jira.jboss.org/jira/browse/JBID-127
>             Project: JBoss Identity
>          Issue Type: Task
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 17:51:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 5 Jun 2009 17:51:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-530) Look at using
 refids instead of
 properties to refer to thirdparty jars in the dist build.
In-Reply-To: <13279899.1243637036330.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26031944.1244238716366.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Paul Gier closed JBBUILD-530.
-----------------------------

    Resolution: Done


Fixed in trunk.

> Look at using refids instead of properties to refer to thirdparty jars in the dist build.
> -----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-530
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-530
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the AS distribution build uses properties set by the maven ant tasks to access the various thirdparty dependencies.
> It might be better to use refids since this will cause the build to immediately fail when one is expected but not found.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 19:50:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Fri, 5 Jun 2009 19:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-734) Advisor does not
 treat javassist.NotFoundException
Message-ID: <26146146.1244245856689.JavaMail.jira@cloud.prod.atl2.jboss.com>

Advisor does not treat javassist.NotFoundException
--------------------------------------------------

                 Key: JBAOP-734
                 URL: https://jira.jboss.org/jira/browse/JBAOP-734
             Project: JBoss AOP
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.1.GA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: 2.2.0.GA


When using other agent-enabled tools with JBoss AOP, we may run into a class that contains a field, method, constructor or whatever that was not loaded by Javassist.
In this case, when we try to manipulate that method, constructor or field using javassist we will get a javassist.NotFoundException. Instead of throwing this exception, we need to ignore it and consider the field non-existent.

Here is a concrete scenario: when using Eclipse TPTP (http://www.eclipse.org/tptp/) to profile JBoss AS we get the following AS log:
15:05:55,390 INFO  [Server] Starting JBoss (MX MicroKernel)...
15:05:55,394 INFO  [Server] Release ID: JBoss [EAP] 4.3.0.GA_CP04 (build: SVNTag=JBPAPP_4_3_0_GA_CP04 date=200902200048)
15:05:55,396 INFO  [Server] Home Dir: /usr/local/java/jboss/as/jboss-eap-4.3/jboss-as
15:05:55,396 INFO  [Server] Home URL: file:/usr/local/java/jboss/as/jboss-eap-4.3/jboss-as/
15:05:55,397 INFO  [Server] Patch URL: null
15:05:55,397 INFO  [Server] Server Name: eapDemo
15:05:55,398 INFO  [Server] Server Home Dir: /usr/local/java/jboss/as/jboss-eap-4.3/jboss-as/server/eapDemo
15:05:55,398 INFO  [Server] Server Home URL: file:/usr/local/java/jboss/as/jboss-eap-4.3/jboss-as/server/eapDemo/
15:05:55,398 INFO  [Server] Server Log Dir: /usr/local/java/jboss/as/jboss-eap-4.3/jboss-as/server/eapDemo/log
15:05:55,398 INFO  [Server] Server Temp Dir: /usr/local/java/jboss/as/jboss-eap-4.3/jboss-as/server/eapDemo/tmp
15:05:55,398 INFO  [Server] Root Deployment Filename: jboss-service.xml
15:05:55,924 INFO  [ServerInfo] Java version: 1.5.0_16,Sun Microsystems Inc.
15:05:55,924 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_16-b02,Sun Microsystems Inc.
15:05:55,924 INFO  [ServerInfo] OS-System: Linux 2.6.18-92.1.13.el5PAE,i386
15:05:56,450 INFO  [Server] Core system initialized
15:05:59,570 INFO  [WebService] Using RMI server codebase: http://localhost:8083/
15:05:59,572 INFO  [Log4jService$URLWatchTimerTask] Configuring from URL: resource:jboss-log4j.xml
15:06:00,538 INFO  [TransactionManagerService] JBossTS Transaction Service (JTA version) - JBoss Inc.
15:06:00,538 INFO  [TransactionManagerService] Setting up property manager MBean and JMX layer
15:06:01,077 INFO  [TransactionManagerService] Starting recovery manager
15:06:01,364 INFO  [TransactionManagerService] Recovery manager started
15:06:01,365 INFO  [TransactionManagerService] Binding TransactionManager JNDI Reference
15:06:05,223 INFO  [EJB3Deployer] Starting java:comp multiplexer
15:06:09,714 INFO  [NativeServerConfig] JBoss Web Services - Native
15:06:09,715 INFO  [NativeServerConfig] jbossws-native-2.0.1.SP2_CP05 (build=200902200020)
15:06:11,014 INFO  [AprLifecycleListener] The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/local/java/jdk1.5.0_16/jre/lib/i386/server:/usr/local/java/jdk1.5.0_16/jre/lib/i386:/usr/local/java/jdk1.5.0_16/jre/../lib/i386:/usr/local/java/jboss/jbds/jbdevstudio/eclipse/plugins/org.eclipse.tptp.platform.ac.linux_ia32_4.4.100.v200902101418/agent_controller/bin:/usr/local/java/jboss/jbds/jbdevstudio/eclipse/plugins/org.eclipse.tptp.platform.ac.linux_ia32_4.4.100.v200902101418/agent_controller/lib:/usr/local/java/jboss/jbds/jbdevstudio/eclipse/plugins/org.eclipse.tptp.platform.jvmti.runtime_4.4.201.v200902180100/agent_files/linux_ia32:/usr/local/java/jboss/jbds/jbdevstudio/eclipse/plugins/org.eclipse.hyades.probekit_4.2.401.v200901290100//os/linux/x86:/usr/local/java/jdk1.5.0_16/jre/lib/i386/client:/usr/local/java/jdk1.5.0_16/jre/lib/i386:/usr/lib/xulrunner-1.9:/usr/lib/xulrunner-1.9
15:06:11,180 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-localhost%2F127.0.0.1-8080
15:06:11,180 INFO  [AjpProtocol] Initializing Coyote AJP/1.3 on ajp-localhost%2F127.0.0.1-8009
15:06:11,181 INFO  [Catalina] Initialization processed in 404 ms
15:06:11,181 INFO  [StandardService] Starting service jboss.web
15:06:11,183 INFO  [StandardEngine] Starting Servlet Engine: JBossWeb/2.0.0.GA_CP
15:06:11,293 INFO  [Catalina] Server startup in 112 ms
15:06:11,428 INFO  [TomcatDeployer] deploy, ctxPath=/, warUrl=.../deploy/jboss-web.deployer/ROOT.war/
15:06:12,353 INFO  [TomcatDeployer] deploy, ctxPath=/invoker, warUrl=.../deploy/http-invoker.sar/invoker.war/
15:06:12,704 INFO  [TomcatDeployer] deploy, ctxPath=/jbossws, warUrl=.../deploy/jbossws.sar/jbossws-context.war/
15:06:13,024 INFO  [TomcatDeployer] deploy, ctxPath=/web-console, warUrl=.../deploy/management/console-mgr.sar/web-console.war/
15:06:13,657 INFO  [MailService] Mail Service bound to java:/Mail
15:06:13,798 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-ha-local-jdbc.rar
15:06:13,831 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-ha-xa-jdbc.rar
15:06:13,855 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-local-jdbc.rar
15:06:13,878 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-xa-jdbc.rar
15:06:13,949 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jms-ra.rar
15:06:13,977 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/mail-ra.rar
15:06:14,025 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/quartz-ra.rar
15:06:14,041 INFO  [QuartzResourceAdapter] start quartz!!!
15:06:14,170 INFO  [SimpleThreadPool] Job execution threads will use class loader of thread: main
15:06:14,260 INFO  [QuartzScheduler] Quartz Scheduler v.1.5.2 created.
15:06:14,266 INFO  [RAMJobStore] RAMJobStore initialized.
15:06:14,266 INFO  [StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
15:06:14,266 INFO  [StdSchedulerFactory] Quartz scheduler version: 1.5.2
15:06:14,266 INFO  [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
15:06:15,151 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
15:06:15,683 WARN  [SecurityMetadataStore] 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.
15:06:15,705 INFO  [ServerPeer] JBoss Messaging 1.4.0.SP3-CP07 server [0] started
15:06:16,034 ERROR [ExceptionUtil] org.jboss.jms.server.connectionfactory.ConnectionFactory at f65b5b startService
java.lang.ExceptionInInitializerError
   at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:182)
   at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:204)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy42.start(Unknown Source)
   at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:202)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy9.deploy(Unknown Source)
   at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
   at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy5.deploy(Unknown Source)
   at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
   at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
   at org.jboss.Main.boot(Main.java:200)
   at org.jboss.Main$1.run(Main.java:508)
   at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at org.jboss.aop.pointcut.FieldMatcher.visit(FieldMatcher.java:181)
   at org.jboss.aop.pointcut.ast.ASTAll.jjtAccept(ASTAll.java:41)
   at org.jboss.aop.pointcut.MatcherHelper.visit(MatcherHelper.java:88)
   at org.jboss.aop.pointcut.MatcherHelper.matches(MatcherHelper.java:83)
   at org.jboss.aop.pointcut.PointcutExpression.matchesGet(PointcutExpression.java:154)
   at org.jboss.aop.ClassAdvisor.resolveFieldPointcut(ClassAdvisor.java:431)
   at org.jboss.aop.ClassAdvisor.createInterceptorChains(ClassAdvisor.java:608)
   at org.jboss.aop.ClassAdvisor.access$300(ClassAdvisor.java:82)
   at org.jboss.aop.ClassAdvisor$1.run(ClassAdvisor.java:299)
   at java.security.AccessController.doPrivileged(Native Method)
   at org.jboss.aop.ClassAdvisor.attachClass(ClassAdvisor.java:271)
   at org.jboss.aop.AspectManager.initialiseClassAdvisor(AspectManager.java:591)
   at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:579)
   at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.<clinit>(ClientConnectionFactoryDelegate.java)
   ... 120 more
Caused by: java.lang.RuntimeException: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:405)
   at org.jboss.aop.pointcut.FieldMatcher.visit(FieldMatcher.java:177)
   ... 133 more
Caused by: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at javassist.CtClassType.getField(CtClassType.java:822)
   at org.jboss.aop.util.ReflectToJavassist.fieldToJavassist(ReflectToJavassist.java:55)
   at org.jboss.aop.annotation.PortableAnnotationElement.isAnyAnnotationPresent(PortableAnnotationElement.java:113)
   at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:401)
   ... 134 more
15:06:16,037 WARN  [ServiceController] Problem starting service jboss.messaging.connectionfactory:service=ConnectionFactory
java.lang.ExceptionInInitializerError
   at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:182)
   at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:204)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy42.start(Unknown Source)
   at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:202)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy9.deploy(Unknown Source)
   at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
   at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy5.deploy(Unknown Source)
   at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
   at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
   at org.jboss.Main.boot(Main.java:200)
   at org.jboss.Main$1.run(Main.java:508)
   at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at org.jboss.aop.pointcut.FieldMatcher.visit(FieldMatcher.java:181)
   at org.jboss.aop.pointcut.ast.ASTAll.jjtAccept(ASTAll.java:41)
   at org.jboss.aop.pointcut.MatcherHelper.visit(MatcherHelper.java:88)
   at org.jboss.aop.pointcut.MatcherHelper.matches(MatcherHelper.java:83)
   at org.jboss.aop.pointcut.PointcutExpression.matchesGet(PointcutExpression.java:154)
   at org.jboss.aop.ClassAdvisor.resolveFieldPointcut(ClassAdvisor.java:431)
   at org.jboss.aop.ClassAdvisor.createInterceptorChains(ClassAdvisor.java:608)
   at org.jboss.aop.ClassAdvisor.access$300(ClassAdvisor.java:82)
   at org.jboss.aop.ClassAdvisor$1.run(ClassAdvisor.java:299)
   at java.security.AccessController.doPrivileged(Native Method)
   at org.jboss.aop.ClassAdvisor.attachClass(ClassAdvisor.java:271)
   at org.jboss.aop.AspectManager.initialiseClassAdvisor(AspectManager.java:591)
   at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:579)
   at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.<clinit>(ClientConnectionFactoryDelegate.java)
   ... 120 more
Caused by: java.lang.RuntimeException: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:405)
   at org.jboss.aop.pointcut.FieldMatcher.visit(FieldMatcher.java:177)
   ... 133 more
Caused by: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at javassist.CtClassType.getField(CtClassType.java:822)
   at org.jboss.aop.util.ReflectToJavassist.fieldToJavassist(ReflectToJavassist.java:55)
   at org.jboss.aop.annotation.PortableAnnotationElement.isAnyAnnotationPresent(PortableAnnotationElement.java:113)
   at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:401)
   ... 134 more
15:06:16,039 INFO  [ConnectionFactoryJNDIMapper] supportsFailover attribute is true on connection factory: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory but post office is non clustered. So connection factory will *not* support failover
15:06:16,039 INFO  [ConnectionFactoryJNDIMapper] supportsLoadBalancing attribute is true on connection factory: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory but post office is non clustered. So connection factory will *not* support load balancing
15:06:16,039 ERROR [ExceptionUtil] org.jboss.jms.server.connectionfactory.ConnectionFactory at 11e1813 startService
java.lang.NoClassDefFoundError
   at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:182)
   at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:204)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy42.start(Unknown Source)
   at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:202)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy9.deploy(Unknown Source)
   at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
   at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy5.deploy(Unknown Source)
   at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
   at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
   at org.jboss.Main.boot(Main.java:200)
   at org.jboss.Main$1.run(Main.java:508)
   at java.lang.Thread.run(Thread.java:595)
15:06:16,040 WARN  [ServiceController] Problem starting service jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
java.lang.NoClassDefFoundError
   at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:182)
   at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:204)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy42.start(Unknown Source)
   at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:202)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy9.deploy(Unknown Source)
   at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
   at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy5.deploy(Unknown Source)
   at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
   at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
   at org.jboss.Main.boot(Main.java:200)
   at org.jboss.Main$1.run(Main.java:508)
   at java.lang.Thread.run(Thread.java:595)
15:06:16,041 ERROR [ExceptionUtil] org.jboss.jms.server.connectionfactory.ConnectionFactory at be9340 startService
java.lang.NoClassDefFoundError
   at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:182)
   at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:204)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy42.start(Unknown Source)
   at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:202)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy9.deploy(Unknown Source)
   at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
   at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy5.deploy(Unknown Source)
   at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
   at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
   at org.jboss.Main.boot(Main.java:200)
   at org.jboss.Main$1.run(Main.java:508)
   at java.lang.Thread.run(Thread.java:595)
15:06:16,042 WARN  [ServiceController] Problem starting service jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
java.lang.NoClassDefFoundError
   at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:182)
   at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:204)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy42.start(Unknown Source)
   at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:202)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy9.deploy(Unknown Source)
   at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
   at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy5.deploy(Unknown Source)
   at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
   at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
   at org.jboss.Main.boot(Main.java:200)
   at org.jboss.Main$1.run(Main.java:508)
   at java.lang.Thread.run(Thread.java:595)
15:06:16,062 INFO  [QueueService] Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,063 INFO  [QueueService] Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,066 INFO  [TopicService] Topic[/topic/testTopic] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,130 INFO  [TopicService] Topic[/topic/securedTopic] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,132 INFO  [TopicService] Topic[/topic/testDurableTopic] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,148 INFO  [QueueService] Queue[/queue/testQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,182 INFO  [QueueService] Queue[/queue/A] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,185 INFO  [QueueService] Queue[/queue/B] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,187 INFO  [QueueService] Queue[/queue/C] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,189 INFO  [QueueService] Queue[/queue/D] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,191 INFO  [QueueService] Queue[/queue/ex] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,193 INFO  [QueueService] Queue[/queue/PrivateDLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,194 INFO  [QueueService] Queue[/queue/PrivateExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,208 INFO  [QueueService] Queue[/queue/QueueWithOwnDLQAndExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,209 INFO  [TopicService] Topic[/topic/TopicWithOwnDLQAndExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,211 INFO  [QueueService] Queue[/queue/QueueWithOwnRedeliveryDelay] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,212 INFO  [TopicService] Topic[/topic/TopicWithOwnRedeliveryDelay] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,214 INFO  [QueueService] Queue[/queue/testDistributedQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,215 INFO  [TopicService] Topic[/topic/testDistributedTopic] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,598 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
15:06:16,625 INFO  [TomcatDeployer] deploy, ctxPath=/jmx-console, warUrl=.../deploy/jmx-console.war/
15:06:16,791 ERROR [URLDeploymentScanner] Incomplete Deployment listing:

--- MBeans waiting for other MBeans ---
ObjectName: jboss.messaging.connectionfactory:service=ConnectionFactory
 State: FAILED
 Reason: java.lang.ExceptionInInitializerError
 I Depend On:
   jboss.messaging:service=ServerPeer
   jboss.messaging:service=Connector,transport=bisocket
   jboss.messaging:service=PostOffice

ObjectName: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
 State: FAILED
 Reason: java.lang.NoClassDefFoundError
 I Depend On:
   jboss.messaging:service=ServerPeer
   jboss.messaging:service=Connector,transport=bisocket
   jboss.messaging:service=PostOffice

ObjectName: jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
 State: FAILED
 Reason: java.lang.NoClassDefFoundError
 I Depend On:
   jboss.messaging:service=ServerPeer
   jboss.messaging:service=Connector,transport=bisocket
   jboss.messaging:service=PostOffice

--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.messaging.connectionfactory:service=ConnectionFactory
 State: FAILED
 Reason: java.lang.ExceptionInInitializerError
 I Depend On:
   jboss.messaging:service=ServerPeer
   jboss.messaging:service=Connector,transport=bisocket
   jboss.messaging:service=PostOffice

ObjectName: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
 State: FAILED
 Reason: java.lang.NoClassDefFoundError
 I Depend On:
   jboss.messaging:service=ServerPeer
   jboss.messaging:service=Connector,transport=bisocket
   jboss.messaging:service=PostOffice

ObjectName: jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
 State: FAILED
 Reason: java.lang.NoClassDefFoundError
 I Depend On:
   jboss.messaging:service=ServerPeer
   jboss.messaging:service=Connector,transport=bisocket
   jboss.messaging:service=PostOffice


15:06:17,043 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-localhost%2F127.0.0.1-8080
15:06:17,066 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-localhost%2F127.0.0.1-8009
15:06:17,074 INFO  [Server] JBoss (MX MicroKernel) [4.3.0.GA_CP04 (build: SVNTag=JBPAPP_4_3_0_GA_CP04 date=200902200048)] Started in 21s:672ms
15:06:27,192 ERROR [MessagingXAResourceWrapper] ********************************Failed to connect to server
javax.naming.NameNotFoundException: XAConnectionFactory not bound
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:581)
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:589)
   at org.jnp.server.NamingServer.getObject(NamingServer.java:595)
   at org.jnp.server.NamingServer.lookup(NamingServer.java:342)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
   at javax.naming.InitialContext.lookup(InitialContext.java:351)
   at org.jboss.util.naming.Util.lookup(Util.java:215)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getConnectionFactory(MessagingXAResourceWrapper.java:354)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.connect(MessagingXAResourceWrapper.java:300)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:259)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.recover(MessagingXAResourceWrapper.java:107)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:746)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:685)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)
15:06:27,199 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException: Error trying to connect to provider java:/DefaultJMSProvider, XAException.XAER_RMERR
15:06:27,199 ERROR [MessagingXAResourceWrapper] ********************************Failed to connect to server
javax.naming.NameNotFoundException: XAConnectionFactory not bound
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:581)
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:589)
   at org.jnp.server.NamingServer.getObject(NamingServer.java:595)
   at org.jnp.server.NamingServer.lookup(NamingServer.java:342)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
   at javax.naming.InitialContext.lookup(InitialContext.java:351)
   at org.jboss.util.naming.Util.lookup(Util.java:215)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getConnectionFactory(MessagingXAResourceWrapper.java:354)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.connect(MessagingXAResourceWrapper.java:300)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:259)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.recover(MessagingXAResourceWrapper.java:107)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:771)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:685)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)
15:08:37,265 ERROR [MessagingXAResourceWrapper] ********************************Failed to connect to server
javax.naming.NameNotFoundException: XAConnectionFactory not bound
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:581)
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:589)
   at org.jnp.server.NamingServer.getObject(NamingServer.java:595)
   at org.jnp.server.NamingServer.lookup(NamingServer.java:342)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
   at javax.naming.InitialContext.lookup(InitialContext.java:351)
   at org.jboss.util.naming.Util.lookup(Util.java:215)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getConnectionFactory(MessagingXAResourceWrapper.java:354)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.connect(MessagingXAResourceWrapper.java:300)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:259)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.recover(MessagingXAResourceWrapper.java:107)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:746)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:685)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)
15:08:37,269 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException: Error trying to connect to provider java:/DefaultJMSProvider, XAException.XAER_RMERR
15:08:37,271 ERROR [MessagingXAResourceWrapper] ********************************Failed to connect to server
javax.naming.NameNotFoundException: XAConnectionFactory not bound
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:581)
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:589)
   at org.jnp.server.NamingServer.getObject(NamingServer.java:595)
   at org.jnp.server.NamingServer.lookup(NamingServer.java:342)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
   at javax.naming.InitialContext.lookup(InitialContext.java:351)
   at org.jboss.util.naming.Util.lookup(Util.java:215)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getConnectionFactory(MessagingXAResourceWrapper.java:354)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.connect(MessagingXAResourceWrapper.java:300)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:259)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.recover(MessagingXAResourceWrapper.java:107)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:771)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:685)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)
15:10:47,343 ERROR [MessagingXAResourceWrapper] ********************************Failed to connect to server
javax.naming.NameNotFoundException: XAConnectionFactory not bound
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:581)
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:589)
   at org.jnp.server.NamingServer.getObject(NamingServer.java:595)
   at org.jnp.server.NamingServer.lookup(NamingServer.java:342)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
   at javax.naming.InitialContext.lookup(InitialContext.java:351)
   at org.jboss.util.naming.Util.lookup(Util.java:215)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getConnectionFactory(MessagingXAResourceWrapper.java:354)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.connect(MessagingXAResourceWrapper.java:300)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:259)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.recover(MessagingXAResourceWrapper.java:107)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:746)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:685)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)
15:10:47,347 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException: Error trying to connect to provider java:/DefaultJMSProvider, XAException.XAER_RMERR
15:10:47,348 ERROR [MessagingXAResourceWrapper] ********************************Failed to connect to server
javax.naming.NameNotFoundException: XAConnectionFactory not bound
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:581)
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:589)
   at org.jnp.server.NamingServer.getObject(NamingServer.java:595)
   at org.jnp.server.NamingServer.lookup(NamingServer.java:342)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
   at javax.naming.InitialContext.lookup(InitialContext.java:351)
   at org.jboss.util.naming.Util.lookup(Util.java:215)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getConnectionFactory(MessagingXAResourceWrapper.java:354)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.connect(MessagingXAResourceWrapper.java:300)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:259)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.recover(MessagingXAResourceWrapper.java:107)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:771)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:685)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)



The central point of this log is the stack trace:

Caused by: java.lang.RuntimeException: java.lang.RuntimeException: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at org.jboss.aop.pointcut.FieldMatcher.visit(FieldMatcher.java:181)
   at org.jboss.aop.pointcut.ast.ASTAll.jjtAccept(ASTAll.java:41)
   at org.jboss.aop.pointcut.MatcherHelper.visit(MatcherHelper.java:88)
   at org.jboss.aop.pointcut.MatcherHelper.matches(MatcherHelper.java:83)
   at org.jboss.aop.pointcut.PointcutExpression.matchesGet(PointcutExpression.java:154)
   at org.jboss.aop.ClassAdvisor.resolveFieldPointcut(ClassAdvisor.java:431)
   at org.jboss.aop.ClassAdvisor.createInterceptorChains(ClassAdvisor.java:608)
   at org.jboss.aop.ClassAdvisor.access$300(ClassAdvisor.java:82)
   at org.jboss.aop.ClassAdvisor$1.run(ClassAdvisor.java:299)
   at java.security.AccessController.doPrivileged(Native Method)
   at org.jboss.aop.ClassAdvisor.attachClass(ClassAdvisor.java:271)
   at org.jboss.aop.AspectManager.initialiseClassAdvisor(AspectManager.java:591)
   at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:579)
   at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.<clinit>(ClientConnectionFactoryDelegate.java)
   ... 120 more
Caused by: java.lang.RuntimeException: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:405)
   at org.jboss.aop.pointcut.FieldMatcher.visit(FieldMatcher.java:177)
   ... 133 more 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 04:21:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 8 Jun 2009 04:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7001) Create a stand-alone
 JBossWeb integration project
Message-ID: <4203295.1244449316600.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create a stand-alone JBossWeb integration project
-------------------------------------------------

                 Key: JBAS-7001
                 URL: https://jira.jboss.org/jira/browse/JBAS-7001
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf


Create a stand-alone integration implementation of Tomcat and VDF usable in AS, Embedded and other runtimes based on Bootstrap.

The working title is 'Spider'.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 04:24:01 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Mon, 8 Jun 2009 04:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6937) Bad deployment scan
	order?
In-Reply-To: <23627422.1242664685223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <808154.1244449441761.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Emanuel Muckenhuber resolved JBAS-6937.
---------------------------------------

    Resolution: Out of Date


This does not seem to be an issue any more, at least i can't reproduce it. In case you still see  problems feel free to reopen and update the description.

> Bad deployment scan order?
> --------------------------
>
>                 Key: JBAS-6937
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6937
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers, ProfileService
>            Reporter: Ondrej ?i?ka
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: EARwithWAR-handmade.zip
>
>
> Steps to reproduce:
> 1) Download attached EARwithWAR-handmade.zip and unzip
> 2) Hot-deploy the contained directory - EARwithWAR-handmade
> 3) Check the deployment info (in EmbJopr)  - a WAR contained inside appears
> 4) In the deploy dir, add '.ear' to the name of 'EARwithWAR-handmade' - rename to 'EARwithWAR-handmade.ear'
> 5) Now check the deployment info in EmbJopr. You will see:
>    - the WAR is DOWN
>   - new EAR appeared, but is also  down
> 6) After invoking the Start op on EAR, everything gets to the right state.
> (18:14:46) ozizka: emuckenhuber: I've noticed one interesting thing. AS 5 deployment scanner first scans what's new and then what was removed. Shouldn't it be the opposite way?
> (18:20:34) emuckenhuber: ozizka: well it first scans for removal and then for additions - where do you see that ?
> (18:20:47) ozizka: I've tried it this way:
> (18:21:18) ozizka: It scans recursively, so I've created an exploded ear directory, only without the .ear suffix.
> (18:21:28) ozizka: So AS scanned, found the .war inside this dir,
> (18:21:34) ozizka: and deployed it.
> (18:21:49) ozizka: Then I renamed the directory - added the .ear suffix,
> (18:22:01) ozizka: so what should happen IMO is first undeploying WAR,
> (18:22:11) ozizka: and then deploying newly found exploded EAR
> (18:22:24) ozizka: I know it's not usual use case :)
> (18:22:45) ozizka: But instead, the WAR is reported to be DOWN (in EmbJopr)
> (18:23:15) ozizka: and ear appears, but is DOWN too
> (18:24:22) ozizka: When I invoke the Start operation on the ear, everything gets to normal, that is, EAR UP, standalone WAR disappears and Embedded WAR appears and is UP
> 18:25
> (18:26:02) ozizka: emuckenhuber: And to add why I think that deployment is done first is this:
> (18:26:02) ozizka: java.lang.IllegalStateException: jboss.web.deployment:war=/hellothere-inEAR is already installed.
> (18:26:19) ozizka: that happens after the rename

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun  8 04:52:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 8 Jun 2009 04:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1536) Optimisation
In-Reply-To: <9922377.1236104062518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5593556.1244451176451.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil updated JBMESSAGING-1536:
-------------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0 Beta)


> Optimisation
> ------------
>
>                 Key: JBMESSAGING-1536
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1536
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0.CR1
>
>
> Various system optimisations:
> 1) Optimise message routing. We can probably combine preroute and route. Also in BindingsImpl we can  avoid creation of so many sets, and use array based logic instead.
> 2) Optimise SimpleString - intern() where appropriate
> 3) Optimise journal direct byte buffers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 06:02:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 8 Jun 2009 06:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-203) add an option to
 validate just
 built SchemaBinding against the XSD in the default schema resolvers
In-Reply-To: <5112439.1243607876650.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18509705.1244455376692.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Alexey Loubyansky closed JBXB-203.
----------------------------------

    Resolution: Done


Done.

> add an option to validate just built SchemaBinding against the XSD in the default schema resolvers
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBXB-203
>                 URL: https://jira.jboss.org/jira/browse/JBXB-203
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> There was a suggestion to add an option to validate the consistency of SchemaBinding instances built from JAXB/JBossXB annotations against their corresponding XSDs during schema resolution.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 06:19:56 2009
From: jira-events at lists.jboss.org (sarfaraz khan (JIRA))
Date: Mon, 8 Jun 2009 06:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7002) Cannot release
 inactive sessions in oracle
Message-ID: <16823614.1244456396481.JavaMail.jira@cloud.prod.atl2.jboss.com>

Cannot release inactive sessions in oracle 
-------------------------------------------

                 Key: JBAS-7002
                 URL: https://jira.jboss.org/jira/browse/JBAS-7002
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.0.GA
         Environment: RedHat Enterprise Linux AS 
            Reporter: sarfaraz khan
            Priority: Critical


My application is running in jboss .
when ever i execute a query from my application to database a session is created in oracle in ACTIVE mode.
Then after some time is it converted to INACTIVE mode
if my application runs more than 3 hours then more than 130 INACTIVE session created in oracle.

if i close the jboss then there is no INACTIVE session available.
so it is clear that JBOSS is not releasing connections.

my orcle-ds.xml is like this

<datasources>
	<local-tx-datasource>

		<jndi-name>cseDS</jndi-name>
		<use-java-context>false</use-java-context>
		<connection-url>jdbc:oracle:thin:@172.20.6.184:1531:csesrvcm</connection-url>
		<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
		<user-name>auditdba</user-name>
		<password>abcd1234</password>
		<min-pool-size>5</min-pool-size>
		<max-pool-size>50</max-pool-size>
		<idle-timeout-minutes>3</idle-timeout-minutes>

	</local-tx-datasource>
</datasources>


Please suggest me how to realease all inactive sessions in database.

it is an critical issue.my application is in production server .. please help me  ???

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 06:57:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Mon, 8 Jun 2009 06:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (RELOADED-8) Create a JSR-250
 compliant injection framework on top of VDF
In-Reply-To: <3377495.1242033106555.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7412885.1244458676737.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/RELOADED-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470961#action_12470961 ] 

Richard Opalka commented on RELOADED-8:
---------------------------------------

I'm little bit confused:( Will this issue address only JSR-250 spec. or injection in general?

> Create a JSR-250 compliant injection framework on top of VDF
> ------------------------------------------------------------
>
>                 Key: RELOADED-8
>                 URL: https://jira.jboss.org/jira/browse/RELOADED-8
>             Project: JBoss Reloaded
>          Issue Type: Feature Request
>          Components: injection
>    Affects Versions: injection-0.1.0
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 06:59:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Mon, 8 Jun 2009 06:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (RELOADED-8) Create a JSR-250
 compliant injection framework on top of VDF
In-Reply-To: <3377495.1242033106555.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14001318.1244458796930.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/RELOADED-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470962#action_12470962 ] 

Richard Opalka commented on RELOADED-8:
---------------------------------------

Identified JBossWS Project Injection Requirements:

JSR-250 - Common Java Annotations for Java Platform

JSR-244 - Java Platform, Enterprise Edition (a.k.a. Java EE 5)
 - Chapter 5.2.3 - Annotations and Injection

I identified injection related sections from JBossWS project perspective:
JSR-224 - The Java API for XML Web Services (a.k.a JAX-WS 2.1)
 - Chapter 5.2.1 - Endpoint Usage
 - Chapter 5.3 - javax.xml.ws.WebServiceContext
 - Chapter 7.9 - javax.xml.ws.WebServiceRef
 - Chapter 7.10 - javax.xml.ws.WebServiceRefs
 - Chapter 9.3.1 - Handler Lifecycle

https://jira.jboss.org/jira/browse/JBWS-2634
 - although not explicitly specified in any of the above specs
   we implemented the @EJB injection support in JBossWS components.
   This feature is required from JSR-244 -> Chapter 5.2.3 -> Table EE.5-1 (IOHO)

I'd put these requirements to associated jboss-dev thread, but forums seem to be unfunctional now.

> Create a JSR-250 compliant injection framework on top of VDF
> ------------------------------------------------------------
>
>                 Key: RELOADED-8
>                 URL: https://jira.jboss.org/jira/browse/RELOADED-8
>             Project: JBoss Reloaded
>          Issue Type: Feature Request
>          Components: injection
>    Affects Versions: injection-0.1.0
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 07:03:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Mon, 8 Jun 2009 07:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (RELOADED-8) Create a JSR-250
 compliant injection framework on top of VDF
In-Reply-To: <3377495.1242033106555.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14895757.1244459037006.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Richard Opalka updated RELOADED-8:
----------------------------------

    Comment: was deleted


> Create a JSR-250 compliant injection framework on top of VDF
> ------------------------------------------------------------
>
>                 Key: RELOADED-8
>                 URL: https://jira.jboss.org/jira/browse/RELOADED-8
>             Project: JBoss Reloaded
>          Issue Type: Feature Request
>          Components: injection
>    Affects Versions: injection-0.1.0
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 07:03:57 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Mon, 8 Jun 2009 07:03:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (RELOADED-8) Create a JSR-250
 compliant injection framework on top of VDF
In-Reply-To: <3377495.1242033106555.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23021613.1244459037910.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Richard Opalka updated RELOADED-8:
----------------------------------

    Comment: was deleted


> Create a JSR-250 compliant injection framework on top of VDF
> ------------------------------------------------------------
>
>                 Key: RELOADED-8
>                 URL: https://jira.jboss.org/jira/browse/RELOADED-8
>             Project: JBoss Reloaded
>          Issue Type: Feature Request
>          Components: injection
>    Affects Versions: injection-0.1.0
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 07:03:57 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Mon, 8 Jun 2009 07:03:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (RELOADED-8) Create a JSR-250
 compliant injection framework on top of VDF
In-Reply-To: <3377495.1242033106555.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31650864.1244459037426.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/RELOADED-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470963#action_12470963 ] 

Richard Opalka commented on RELOADED-8:
---------------------------------------

Identified JBossWS Project Injection Requirements:

JSR-244 - Java Platform, Enterprise Edition (a.k.a. Java EE 5)
 - Chapter 5.2.3 - Annotations and Injection

JSR-224 - The Java API for XML Web Services (a.k.a JAX-WS 2.1)
 - Chapter 5.2.1 - Endpoint Usage
 - Chapter 5.3 - javax.xml.ws.WebServiceContext
 - Chapter 7.9 - javax.xml.ws.WebServiceRef
 - Chapter 7.10 - javax.xml.ws.WebServiceRefs
 - Chapter 9.3.1 - Handler Lifecycle

https://jira.jboss.org/jira/browse/JBWS-2634
 - although not explicitly specified in any of the above specs
   we implemented the @EJB injection support in JBossWS components.
   This feature is required from JSR-244 -> Chapter 5.2.3 -> Table EE.5-1 (IOHO)

I'd put these requirements to associated jboss-dev thread, but forums seem to be unfunctional now. 


> Create a JSR-250 compliant injection framework on top of VDF
> ------------------------------------------------------------
>
>                 Key: RELOADED-8
>                 URL: https://jira.jboss.org/jira/browse/RELOADED-8
>             Project: JBoss Reloaded
>          Issue Type: Feature Request
>          Components: injection
>    Affects Versions: injection-0.1.0
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 07:31:56 2009
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Mon, 8 Jun 2009 07:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7002) Cannot release
 inactive sessions in oracle
In-Reply-To: <16823614.1244456396481.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9963294.1244460716471.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Adrian Brock closed JBAS-7002.
------------------------------

    Resolution: Rejected


Use the forums to ask to help.


> Cannot release inactive sessions in oracle 
> -------------------------------------------
>
>                 Key: JBAS-7002
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7002
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.0.GA
>         Environment: RedHat Enterprise Linux AS 
>            Reporter: sarfaraz khan
>            Priority: Critical
>
> My application is running in jboss .
> when ever i execute a query from my application to database a session is created in oracle in ACTIVE mode.
> Then after some time is it converted to INACTIVE mode
> if my application runs more than 3 hours then more than 130 INACTIVE session created in oracle.
> if i close the jboss then there is no INACTIVE session available.
> so it is clear that JBOSS is not releasing connections.
> my orcle-ds.xml is like this
> <datasources>
> 	<local-tx-datasource>
> 		<jndi-name>cseDS</jndi-name>
> 		<use-java-context>false</use-java-context>
> 		<connection-url>jdbc:oracle:thin:@172.20.6.184:1531:csesrvcm</connection-url>
> 		<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
> 		<user-name>auditdba</user-name>
> 		<password>abcd1234</password>
> 		<min-pool-size>5</min-pool-size>
> 		<max-pool-size>50</max-pool-size>
> 		<idle-timeout-minutes>3</idle-timeout-minutes>
> 	</local-tx-datasource>
> </datasources>
> Please suggest me how to realease all inactive sessions in database.
> it is an critical issue.my application is in production server .. please help me  ???

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 09:30:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Mon, 8 Jun 2009 09:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2116) Drools core throws
 OutOfMemoryException
Message-ID: <21984599.1244467856662.JavaMail.jira@cloud.prod.atl2.jboss.com>

Drools core throws OutOfMemoryException
---------------------------------------

                 Key: JBRULES-2116
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2116
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 4.0.7
            Reporter: Andrey Nechaev
            Assignee: Mark Proctor


In some situations, Drools' tuple hash tables become corrupted, as they have loops in a list elements. It causes an infinite loop in the TupleHashTable's resize() method. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 09:32:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Mon, 8 Jun 2009 09:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2116) Drools core throws
 OutOfMemoryException
In-Reply-To: <21984599.1244467856662.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23652495.1244467976528.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrey Nechaev updated JBRULES-2116:
------------------------------------

    Attachment: patch-TupleHashTable


Attachement is the patch for TupleHashTable class. It prevents using lists as a hash table's element. This is not theoptimal solution but it works with some performance and memory consumption degradation.

> Drools core throws OutOfMemoryException
> ---------------------------------------
>
>                 Key: JBRULES-2116
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2116
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 4.0.7
>            Reporter: Andrey Nechaev
>            Assignee: Mark Proctor
>         Attachments: patch-TupleHashTable
>
>
> In some situations, Drools' tuple hash tables become corrupted, as they have loops in a list elements. It causes an infinite loop in the TupleHashTable's resize() method. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 09:54:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 8 Jun 2009 09:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7003) Jopr does not start
	in Branch_5_x
Message-ID: <8325659.1244469296878.JavaMail.jira@cloud.prod.atl2.jboss.com>

Jopr does not start in Branch_5_x
---------------------------------

                 Key: JBAS-7003
                 URL: https://jira.jboss.org/jira/browse/JBAS-7003
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-5.2.0.Beta1


Container task to track any problems relating to Jopr not starting in AS Branch_5_x.

Any runtime/deploytime failures need a corresponding testcase.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 09:58:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 8 Jun 2009 09:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-93) Define
 @ManagementProperty ServerConfig.getSpecificationVersion
Message-ID: <19526088.1244469536566.JavaMail.jira@cloud.prod.atl2.jboss.com>

Define @ManagementProperty ServerConfig.getSpecificationVersion
---------------------------------------------------------------

                 Key: JBBOOT-93
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-93
             Project: JBoss Bootstrap
          Issue Type: Feature Request
          Components: impl-as
    Affects Versions: 2.0.0-alpha-1
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 2.0.0-alpha-2


This is required by Jopr.

09:32:48,964 WARN  [InventoryManager] Failure during discovery for [JBossAS Server] Resources - failed after 6282 ms.
java.lang.Exception: Discovery component invocation failed.
        at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:248)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
        at java.util.concurrent.FutureTask.run(FutureTask.java:123)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalStateException: Property named 'specificationVersion' not found for ManagedComponent [org.jboss.managed.plugins.ManagedComponentImpl at 24b80637{name=jboss.system:type=ServerConfig, type=ComponentType{type=MCBean, subtype=ServerConfig}, owner=ManagedDeployment at 1381870081}].
        at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSimplePropertyValue(ManagedComponentUtils.java:73)
        at org.rhq.plugins.jbossas5.ApplicationServerDiscoveryComponent.discoverInProcessJBossAS(ApplicationServerDiscoveryComponent.java:281)
        at org.rhq.plugins.jbossas5.ApplicationServerDiscoveryComponent.discoverResources(ApplicationServerDiscoveryComponent.java:102)
        at sun.reflect.GeneratedMethodAccessor311.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
        ... 5 more

Legacy has:

ctor:
serverSpecificationVersion = thisPackage.getSpecificationVersion();

@ManagementProperty(description="the server Specification-Version",
         use={ViewUse.STATISTIC})
   public String getSpecificationVersion()
   {
      return serverSpecificationVersion;
   }

Remove the STATISTIC use and mark read-only.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 10:17:00 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 8 Jun 2009 10:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2738) Security Auditing
	Service
Message-ID: <8546865.1244470620842.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana commented on JBAS-2738:
-------------------------------------

http://server.dzone.com/articles/security-auditing-jboss

> Security Auditing Service
> -------------------------
>
>                 Key: JBAS-2738
>                 URL: https://jira.jboss.org/jira/browse/JBAS-2738
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.0.Beta1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.0.0.Beta1
>
>
> A Security Audit Service needs to be implemented that can provide audit logs for various security related customer needs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 10:25:09 2009
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Mon, 8 Jun 2009 10:25:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-189)
 setRequiredStage() does not work
Message-ID: <8854106.1244471109455.JavaMail.jira@cloud.prod.atl2.jboss.com>

setRequiredStage() does not work
--------------------------------

                 Key: JBDEPLOY-189
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-189
             Project: JBoss Deployers
          Issue Type: Bug
          Components: deployer
    Affects Versions: JBDEPLOY-2.0.7.GA, JBDEPLOY-2.0.6.GA
            Reporter: Adrian Brock
            Assignee: Adrian Brock


The feature added in JBDEPLOY-170 does not work and has no tests.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 10:26:57 2009
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Mon, 8 Jun 2009 10:26:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBDEPLOY-189) setRequiredStage()
 does not work
In-Reply-To: <8854106.1244471109455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22030320.1244471217850.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Adrian Brock closed JBDEPLOY-189.
---------------------------------

    Fix Version/s:  JBDEPLOY-2.2.x
                   JBDEPLOY-2.0.8.GA
       Resolution: Done


> setRequiredStage() does not work
> --------------------------------
>
>                 Key: JBDEPLOY-189
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-189
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.6.GA, JBDEPLOY-2.0.7.GA
>            Reporter: Adrian Brock
>            Assignee: Adrian Brock
>             Fix For:  JBDEPLOY-2.2.x, JBDEPLOY-2.0.8.GA
>
>
> The feature added in JBDEPLOY-170 does not work and has no tests.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 10:56:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 8 Jun 2009 10:56:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1641) Stopping the
 bridge service doesn't stop the failure handler
Message-ID: <31429260.1244473017316.JavaMail.jira@cloud.prod.atl2.jboss.com>

Stopping the bridge service doesn't stop the failure handler
------------------------------------------------------------

                 Key: JBMESSAGING-1641
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1641
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.4.GA, 1.4.0.SP3.CP08
            Reporter: Howard Gao
            Assignee: Howard Gao
             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA


when bridge is stopped via the JMX, the stop() action doesn't stop the failure handler, which will keep trying to reconnect even after bridge service has been stopped.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 11:12:56 2009
From: jira-events at lists.jboss.org (Zachary Bedell (JIRA))
Date: Mon, 8 Jun 2009 11:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-204) Validation errors in
 jboss_5_1.xsd
Message-ID: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>

Validation errors in jboss_5_1.xsd
----------------------------------

                 Key: JBMETA-204
                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.0.0.CR17
         Environment: Eclipse 3.4, WebToolsPlatform 3.0
            Reporter: Zachary Bedell
            Assignee: Alexey Loubyansky
            Priority: Critical
             Fix For: 1.0.1.GA


I tried to create a jboss.xml from jboss_5_1.xsd, using Eclipe/WebTools for validation. To achieve this, I picked newest "jboss_5_1.xsd" and "jboss_common_5_1.xsd"  from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/jboss-common_5_1.xsd) and added them to an eclipse web project. The files at http://www.jboss.org/j2ee/schema/ are much older and with more problems...

This results in several problems:
=================
Import of "javaee_5.xsd"  in jboss_common_5_1.xsd does not point to the web location:
<xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>

It should be:
<xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>

=================
Next one is in "jboss_5_1.xsd"

cos-nonambig: "http://www.jboss.com/xml/ns/javaee":security-identity and "http://www.jboss.com/xml/ns/javaee":security-identity (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.	jboss_5_1.xsd

Reason: Element  "security-identity" in "message-driven-beanType" is duplicate.
Same issue was resolved for jboss_5_0.xsd: https://jira.jboss.org/jira/browse/JBMETA-185

=================
jboss_5_1.xsd contains this imports:
   <xsd:include schemaLocation="jboss-common_5_1.xsd"/>

It must point to a valid url: http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd

================
And finally: the usage comment talk about "5.0" and "jboss_5_0.xsd", should be 5.1


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 11:14:56 2009
From: jira-events at lists.jboss.org (Zachary Bedell (JIRA))
Date: Mon, 8 Jun 2009 11:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-204) Validation errors in
 jboss_5_1.xsd (missing webservice-descriptionType)
In-Reply-To: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13515302.1244474096637.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Zachary Bedell updated JBMETA-204:
----------------------------------

              Summary: Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)  (was: Validation errors in jboss_5_1.xsd)
        Fix Version/s:     (was: 1.0.1.GA)
    Affects Version/s: 1.0.1.GA
                           (was: 1.0.0.CR17)
          Description: An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.  (was: I tried to create a jboss.xml from jboss_5_1.xsd, using Eclipe/WebTools for validation. To achieve this, I picked newest "jboss_5_1.xsd" and "jboss_common_5_1.xsd"  from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/jboss-common_5_1.xsd) and added them to an eclipse web project. The files at http://www.jboss.org/j2ee/schema/ are much older and with more problems...

This results in several problems:
=================
Import of "javaee_5.xsd"  in jboss_common_5_1.xsd does not point to the web location:
<xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>

It should be:
<xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>

=================
Next one is in "jboss_5_1.xsd"

cos-nonambig: "http://www.jboss.com/xml/ns/javaee":security-identity and "http://www.jboss.com/xml/ns/javaee":security-identity (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.	jboss_5_1.xsd

Reason: Element  "security-identity" in "message-driven-beanType" is duplicate.
Same issue was resolved for jboss_5_0.xsd: https://jira.jboss.org/jira/browse/JBMETA-185

=================
jboss_5_1.xsd contains this imports:
   <xsd:include schemaLocation="jboss-common_5_1.xsd"/>

It must point to a valid url: http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd

================
And finally: the usage comment talk about "5.0" and "jboss_5_0.xsd", should be 5.1
)


> Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)
> -----------------------------------------------------------------------
>
>                 Key: JBMETA-204
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Zachary Bedell
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>
> An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 11:22:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 8 Jun 2009 11:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-204) Validation errors
 in jboss_5_1.xsd (missing webservice-descriptionType)
In-Reply-To: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10076007.1244474576492.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Alexey Loubyansky commented on JBMETA-204:
------------------------------------------

jboss:webservice-descriptionType is defined in jboss-common_5_1.xsd which is included into jboss_5_1.xsd. So, I guess the include is not being done correctly.

> Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)
> -----------------------------------------------------------------------
>
>                 Key: JBMETA-204
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Zachary Bedell
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>
> An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 11:26:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 8 Jun 2009 11:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-204) Validation errors
 in jboss_5_1.xsd (missing webservice-descriptionType)
In-Reply-To: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5647922.1244474816492.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Alexey Loubyansky commented on JBMETA-204:
------------------------------------------

The online versions of the schemas are out of date. This is one contains webservice-descriptionType http://anonsvn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/resources/schema/jboss-common_5_1.xsd

> Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)
> -----------------------------------------------------------------------
>
>                 Key: JBMETA-204
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Zachary Bedell
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>
> An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 11:49:57 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 8 Jun 2009 11:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-414) XACML:
 ParsingException should also contain the real cause
Message-ID: <12595818.1244476197825.JavaMail.jira@cloud.prod.atl2.jboss.com>

XACML: ParsingException should also contain the real cause
----------------------------------------------------------

                 Key: SECURITY-414
                 URL: https://jira.jboss.org/jira/browse/SECURITY-414
             Project: JBoss Security and Identity Management
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-sunxacml
    Affects Versions: JBossXACML_2.0.3
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: jbossxacml_2.0.3.SP1


The Parsing Exception should also specify the real cause message as part of the exception message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 11:57:56 2009
From: jira-events at lists.jboss.org (Russ Egan (JIRA))
Date: Mon, 8 Jun 2009 11:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1603) EJB with
 dependencies upon itself fails deployment
In-Reply-To: <31197954.1227668256534.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17660666.1244476676776.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471046#action_12471046 ] 

Russ Egan commented on EJBTHREE-1603:
-------------------------------------

Note: this worked in JBoss 4.2.  It was a useful means of controlling transaction boundaries without resorting to bean-managed transactions (by having non-transactional methods exposed by one interface call transactional methods exposed by a different interface, but all implemented by the same bean/service (because maybe both functions need access to some internal shared state).

> EJB with dependencies upon itself fails deployment
> --------------------------------------------------
>
>                 Key: EJBTHREE-1603
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1603
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: Unscheduled
>
>         Attachments: EJBTHREE-1603.patch
>
>
> The following construct:
> @Stateless
> @Remote(SelfDependencyRemoteBusiness.class)
> @Local(SelfDependencyLocalBusiness.class)
> public class SelfDependencyBean implements SelfDependencyLocalBusiness, SelfDependencyRemoteBusiness
> {
>    @EJB
>    private SelfDependencyLocalBusiness local;
> ...
> }
> ...fails deployment:
> 21:55:09,828 WARN  [MainDeployer] Failed to deploy: file:/home/alrubinger/business/jboss/wc/jbossas/projects/ejb3/trunk/testsuite/target/test-lib/ejbthreexxx.jar
> org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> jboss.j2ee:jar=ejbthreexxx.jar,name=SelfDependencyBean,service=EJB3
>  -> <UNKNOWN jboss.j2ee:jar=ejbthreexxx.jar,name=SelfDependencyBean,service=EJB3>{Described:** UNRESOLVED Demands 'jndi:SelfDependencyBean/local-org.jboss.ejb3.test.ejbthreexxx.SelfDependencyLocalBusiness' **}
> *** CONTEXTS IN ERROR: Name -> Error
> <UNKNOWN jboss.j2ee:jar=ejbthreexxx.jar,name=SelfDependencyBean,service=EJB3> -> ** UNRESOLVED Demands 'jndi:SelfDependencyBean/local-org.jboss.ejb3.test.ejbthreexxx.SelfDependencyLocalBusiness' **
> This is the cause of 3 regressions in "asynchronous" tests currently

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 12:00:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 8 Jun 2009 12:00:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-414) XACML:
 ParsingException should also contain the real cause
In-Reply-To: <12595818.1244476197825.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13354769.1244476856434.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed SECURITY-414.
----------------------------------

    Resolution: Done


> XACML: ParsingException should also contain the real cause
> ----------------------------------------------------------
>
>                 Key: SECURITY-414
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-414
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-sunxacml
>    Affects Versions: JBossXACML_2.0.3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP1
>
>
> The Parsing Exception should also specify the real cause message as part of the exception message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 12:18:56 2009
From: jira-events at lists.jboss.org (Zachary Bedell (JIRA))
Date: Mon, 8 Jun 2009 12:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-204) Validation errors
 in jboss_5_1.xsd (missing webservice-descriptionType)
In-Reply-To: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15834392.1244477936587.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Zachary Bedell commented on JBMETA-204:
---------------------------------------

Pulling the full 'schema' directory from svn (r89971) and adjusting all schemaLocation's to reference the pulled & locally hosted files rather than the ones on JBoss' public servers appears to have resolved this issue.

Is there any possibility of modifying the schemas to use relative schema locations rather than fully qualified URL's to public servers?  Bringing a server up in our server network fails miserably as no out-bound HTTP is allowed.  We end up hosting the files on an in-house webserver, but all of the files with literal schemaLocation elements need to be manually edited.

Thanks,
Zac

> Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)
> -----------------------------------------------------------------------
>
>                 Key: JBMETA-204
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Zachary Bedell
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>
> An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 12:36:12 2009
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Mon, 8 Jun 2009 12:36:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4893) JvmRouteValve
 (UseJK) for non session replication setup
In-Reply-To: <15617003.1193112303806.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8514433.1244478973801.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jean-Frederic Clere commented on JBAS-4893:
-------------------------------------------

Won't be moving the issue to the front-end makes sense. The front-end knows where it connects to and therefore knows the "new" JVMRoute.
Probably that should be switch able via a parameter in httpd. 

> JvmRouteValve (UseJK) for non session replication setup
> -------------------------------------------------------
>
>                 Key: JBAS-4893
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4893
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Takayoshi Kimura
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Currently JBoss doesn't install JvmRouteValve for non session
> replication setup. However, it's still useful in the following
> scenario:
> * 1 Apache HTTPD frontend and 2 JBoss AS instances without session replication, sticky session enabled
> * A request goes JBoss node AAA (JSESSIONID=xxx.AAA)
> * The node AAA crashed
> * The request goes node BBB, lost session, recreate another, JSESSIONID won't be changed
> * The node AAA recovered
> * The request comes back to the node AAA, lost session again
> Enabling JvmRouteValve can prevent last failure.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 12:59:56 2009
From: jira-events at lists.jboss.org (Paul Nittel (JIRA))
Date: Mon, 8 Jun 2009 12:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6516) Typo In
 Installation/Getting Started Guide (Version 5 for me)
In-Reply-To: <154239.1234885184491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12414142.1244480396592.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Paul Nittel commented on JBAS-6516:
-----------------------------------

In the same paragraph, "available" is spelled as "avaialble"

> Typo In Installation/Getting Started Guide (Version 5 for me)
> -------------------------------------------------------------
>
>                 Key: JBAS-6516
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6516
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Docs/Installation and Getting Started Guide
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: All where PDF is viewed.
>            Reporter: Michael McElwee
>            Priority: Trivial
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> On the first sentence under Section 1.4 (Project Structure Changes)...page 11 of 100 of the PDF or page 3 on the printed page, the Installation and Getting Started Guide document has the word 'independent' spelled as 'indepdnent'.  Simple typographical error.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 13:07:56 2009
From: jira-events at lists.jboss.org (Joao Paulo Viragine (JIRA))
Date: Mon, 8 Jun 2009 13:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2408) Add option to
 change layout and theme per page in Dashboard.
Message-ID: <14474841.1244480876536.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add option to change layout and theme per page in Dashboard.
------------------------------------------------------------

                 Key: JBPORTAL-2408
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2408
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
         Environment: EPP 4.3
            Reporter: Joao Paulo Viragine
            Priority: Minor


Nowadays we have only the option to change layout and theme for *entire* dashboard (http://www.redhat.com/docs/en-US/Enterprise_Portal_Platform/4.3/html/User_Guide/Portal_User_Guide-JBoss_Portal_Basics-Dashboard.html)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 13:11:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 8 Jun 2009 13:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-190) Fix
	TreeStructureCache
Message-ID: <5441871.1244481116496.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix TreeStructureCache
----------------------

                 Key: JBDEPLOY-190
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-190
             Project: JBoss Deployers
          Issue Type: Bug
          Components: structure
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA


TreeStructureCache shows strange leaves in MC demos.
e.g. node's names do not equal to node's children; empty names vs. 2 children

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 13:13:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 8 Jun 2009 13:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-190) Fix
	TreeStructureCache
In-Reply-To: <5441871.1244481116496.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22413776.1244481236767.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471059#action_12471059 ] 

Ales Justin commented on JBDEPLOY-190:
--------------------------------------

Currently I have a workaround: also update names if (names.size() != children.size()).
But I still don't see why plain null check is not enough.

> Fix TreeStructureCache
> ----------------------
>
>                 Key: JBDEPLOY-190
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-190
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: structure
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>
> TreeStructureCache shows strange leaves in MC demos.
> e.g. node's names do not equal to node's children; empty names vs. 2 children

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 13:40:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 8 Jun 2009 13:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1642) Make the java
 ee example runnable on windows
Message-ID: <22235800.1244482856551.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make the java ee example runnable on windows
--------------------------------------------

                 Key: JBMESSAGING-1642
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1642
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0 Beta
            Reporter: Jeff Mesnil
            Assignee: Tim Fox
             Fix For: 2.0.0.CR1


The javaee examples are hard-coded for Linux (run.sh is used to start JBoss AS).

For windows users, they have to manually edit the build files to sue run.bat instead.
There is a note in the Beta1 release notes about that.

The windows/linux difference should be parameterized so that the same build file
could be used on both OSes.

The windows file (*.bat) must also be checked to ensure they ends with  \r\n

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 16:11:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 8 Jun 2009 16:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-204) Validation errors
 in jboss_5_1.xsd (missing webservice-descriptionType)
In-Reply-To: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29715657.1244491916686.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Alexey Loubyansky commented on JBMETA-204:
------------------------------------------

This is what JBoss AS does. All DTDs and XSDs are resolved locally. Implementation of EntityResolver is responsible for that. Here is http://anonsvn.jboss.org/repos/common/common-core/trunk/src/main/java/org/jboss/util/xml/JBossEntityResolver.java as an example.

> Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)
> -----------------------------------------------------------------------
>
>                 Key: JBMETA-204
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Zachary Bedell
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>
> An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 16:43:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 8 Jun 2009 16:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29563401.1244493836959.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-6888:
---------------------------------


>From the comments above, it appears we'll need an AOP release to address this issue.  Can you provide an update? 

> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Kabir Khan
>         Attachments: server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 19:07:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 8 Jun 2009 19:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1002) EJB3-based
 version of the RetryInterceptor
In-Reply-To: <7722768.1183386630978.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24051609.1244502476931.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471085#action_12471085 ] 

Brian Stansberry commented on EJBTHREE-1002:
--------------------------------------------

Some notes on this as I've been thinking about it a bit.

Assumption is that the basic EJB2 design of storing the cluster topology in JNDI next to the bean ref, using jndiname + fixed_suffix is followed. (That assumption is open to debate if there are better approaches.)

JndiClusteredSessionRegistrarBase would override superclass bind() method to bind the cluster topology objects in JNDI. Objects would either be a FamilyWrapper, or a Reference with a bunch of StringRefAddr, one per target, and an ObjectFactory to create the FamilyWrapper on the client side.

SessionClusteredProxyObjectFactory.createProxyFactoryProxy would be modified to pass the jndiname to ClusteredPojiProxy via a new property setter. Field for this would be transient to ensure serialization format is unchanged. ClusteredPojiProxy would add this name to the invocation metadata.

The actual retry interceptor would be much like the current one, except than once it has created a FamilyWrapper it doesn't need to bind it to the invocation, since FamilyClusterInfo/ClusteringTargetsRepository ensure there is only one set of targets per family.

> EJB3-based version of the RetryInterceptor
> ------------------------------------------
>
>                 Key: EJBTHREE-1002
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1002
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Paul Ferraro
>
> Looking for a conceptual equivalent to the EJB2 RetryInterceptor -- ability to reestablish a valid remoting client when the current FamilyClusterInfo does not contain any valid targets.
> If the approach is analogous to the RetryInterceptor case, what would be registered in JNDI is the FamilyClusterInfo itself (rather than the EJB2 Invoker). Looking this up in JNDI would provide the current list of targets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 01:10:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 9 Jun 2009 01:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-415) ClientLoginModule
 multi-threaded=false should make SecurityContext
 client side association
Message-ID: <12517767.1244524256604.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClientLoginModule multi-threaded=false should make SecurityContext client side association
------------------------------------------------------------------------------------------

                 Key: SECURITY-415
                 URL: https://jira.jboss.org/jira/browse/SECURITY-415
             Project: JBoss Security and Identity Management
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: 2.0.3.SP1
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: 2.0.3.SP2


The ClientLoginModule multi-threaded=false option when missing, should set SecurityContextAssociation.setClient()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 01:18:33 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 9 Jun 2009 01:18:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-131) WS-Kerberos
In-Reply-To: <10099235.1204727998889.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31476750.1244524713241.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana commented on SECURITY-131:
----------------------------------------

http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150953   has a comment

===================
The ticket needs to be forwardable. If it is, in firefox, you add your website to the trusted URIs for delegation ( in about:config). At this point, you should see "context.getDelegState()=true" in the logs.
The missing bit in the jboss-negotiation project is to get the delegated credendentials and store them in the private credentials of the Subject in the SPNEGOLoginModule. It needs to be destroyed or cleared in the logout method.
Then, you will need to manage yourself the kerberos ticket and implement yourself the WS-kerberos (if your webservice is using a HTTP binding, i suppose it would be easy to secure the webservice via spnego). Jboss does not implement these things for you so, you have to take care of the ticket renewal and propagation...

> WS-Kerberos
> -----------
>
>                 Key: SECURITY-131
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-131
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2.0.4.GA
>
>
> Both incomming and outbound.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 01:41:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 9 Jun 2009 01:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1643) Ordering
 Group incorrect handling on Session close
Message-ID: <2086391.1244526116865.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ordering Group incorrect handling on Session close
--------------------------------------------------

                 Key: JBMESSAGING-1643
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1643
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.4.GA, 1.4.0.SP3.CP08
         Environment: all platform
            Reporter: Howard Gao
            Assignee: Howard Gao
             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA


On session close, all unacknowledged messages will be cancelled. For ordering group messages, if messages are cancelled, it will be redelivered first.
But currently if the message is cancelled, the message is released from the ordering group control, making the second message being delivered. That's broken.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 01:45:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Tue, 9 Jun 2009 01:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-735) Fix the
 2.0.x-compliance-tests.xml script
Message-ID: <8383897.1244526356637.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix the 2.0.x-compliance-tests.xml script
-----------------------------------------

                 Key: JBAOP-735
                 URL: https://jira.jboss.org/jira/browse/JBAOP-735
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.1.GA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: 2.1.2.GA


Currently, if you try to run the precompiled-tests_2.0.x target, this is what you get:

_run-precompiled-test_2.0.x:
     [echo] Compiling bridgemethod with optimized=true and instrumentor ${instrumentor}
     [aopc] Exception in thread "main" java.lang.RuntimeException: Invalid instrumentor ${instrumentor} was used
     [aopc] 	at org.jboss.aop.instrument.InstrumentorFactory.initialise(InstrumentorFactory.java:75)
     [aopc] 	at org.jboss.aop.AspectManager$1.run(AspectManager.java:317)
     [aopc] 	at org.jboss.aop.AspectManager$1.run(AspectManager.java:263)
     [aopc] 	at java.security.AccessController.doPrivileged(Native Method)
     [aopc] 	at org.jboss.aop.AspectManager.initManager(AspectManager.java:262)
     [aopc] 	at org.jboss.aop.AspectManager.instance(AspectManager.java:241)
     [aopc] 	at org.jboss.aop.AspectManager.instance(AspectManager.java:230)
     [aopc] 	at org.jboss.aop.standalone.Compiler.compile(Compiler.java:195)
     [aopc] 	at org.jboss.aop.standalone.Compiler.main(Compiler.java:88)

BUILD FAILED
/qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/build-tests-jdk50.xml:275: The following error occurred while executing this line:
/qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:256: The following error occurred while executing this line:
/qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:486: The following error occurred while executing this line:
/qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:287: The following error occurred while executing this line:
/qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:654: Java returned: 1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 01:47:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Tue, 9 Jun 2009 01:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAOP-735) Fix the
 2.0.x-compliance-tests.xml script
In-Reply-To: <8383897.1244526356637.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19415174.1244526476452.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Flavia Rainone resolved JBAOP-735.
----------------------------------

    Resolution: Done


> Fix the 2.0.x-compliance-tests.xml script
> -----------------------------------------
>
>                 Key: JBAOP-735
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-735
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>             Fix For: 2.1.2.GA
>
>
> Currently, if you try to run the precompiled-tests_2.0.x target, this is what you get:
> _run-precompiled-test_2.0.x:
>      [echo] Compiling bridgemethod with optimized=true and instrumentor ${instrumentor}
>      [aopc] Exception in thread "main" java.lang.RuntimeException: Invalid instrumentor ${instrumentor} was used
>      [aopc] 	at org.jboss.aop.instrument.InstrumentorFactory.initialise(InstrumentorFactory.java:75)
>      [aopc] 	at org.jboss.aop.AspectManager$1.run(AspectManager.java:317)
>      [aopc] 	at org.jboss.aop.AspectManager$1.run(AspectManager.java:263)
>      [aopc] 	at java.security.AccessController.doPrivileged(Native Method)
>      [aopc] 	at org.jboss.aop.AspectManager.initManager(AspectManager.java:262)
>      [aopc] 	at org.jboss.aop.AspectManager.instance(AspectManager.java:241)
>      [aopc] 	at org.jboss.aop.AspectManager.instance(AspectManager.java:230)
>      [aopc] 	at org.jboss.aop.standalone.Compiler.compile(Compiler.java:195)
>      [aopc] 	at org.jboss.aop.standalone.Compiler.main(Compiler.java:88)
> BUILD FAILED
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/build-tests-jdk50.xml:275: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:256: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:486: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:287: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:654: Java returned: 1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 01:52:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 9 Jun 2009 01:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1643) Ordering
 Group incorrect handling on Consumer close
In-Reply-To: <2086391.1244526116865.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2060249.1244526776523.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao updated JBMESSAGING-1643:
------------------------------------

        Summary: Ordering Group incorrect handling on Consumer close  (was: Ordering Group incorrect handling on Session close)
    Description: 
On session close, all unacknowledged messages will be cancelled. For ordering group messages, if messages are cancelled, it will be redelivered first.
But currently if the message is cancelled, the message is released from the ordering group control, making the second message being delivered. That's broken.

The reason for the wrong order of delivery:

1. msg A is delivered and commited. then B is delivered to client.
2. consumer close() cause B cancelled back to queue. But it is wrongly removed from the linked list.
3. On next deliver, B cannot be delivered because it is not the first in the ordering group (B still an ordering group message). So C is delivered to client.
4. After C is committed, D is delivered to the client and committed.
5. then B is delivered as the whole ordering group is empty now.

  was:
On session close, all unacknowledged messages will be cancelled. For ordering group messages, if messages are cancelled, it will be redelivered first.
But currently if the message is cancelled, the message is released from the ordering group control, making the second message being delivered. That's broken.





> Ordering Group incorrect handling on Consumer close
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1643
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1643
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: all platform
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> On session close, all unacknowledged messages will be cancelled. For ordering group messages, if messages are cancelled, it will be redelivered first.
> But currently if the message is cancelled, the message is released from the ordering group control, making the second message being delivered. That's broken.
> The reason for the wrong order of delivery:
> 1. msg A is delivered and commited. then B is delivered to client.
> 2. consumer close() cause B cancelled back to queue. But it is wrongly removed from the linked list.
> 3. On next deliver, B cannot be delivered because it is not the first in the ordering group (B still an ordering group message). So C is delivered to client.
> 4. After C is committed, D is delivered to the client and committed.
> 5. then B is delivered as the whole ordering group is empty now.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 03:39:56 2009
From: jira-events at lists.jboss.org (Krashan Brahmanjara (JIRA))
Date: Tue, 9 Jun 2009 03:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6122) Regression: Unable
 to deploy self referencing EJB3 session bean
In-Reply-To: <4298875.1224591920917.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24223943.1244533196882.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Krashan Brahmanjara commented on JBAS-6122:
-------------------------------------------

I can confirm that problem on JBoss 5.1.0GA In my case four ejb bean fails - it works well on Weblogic.

Error log
DEPLOYMENTS MISSING DEPENDENCIES:
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=KBean,service=EJB3" is missing the following dependencies:
    Dependency "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=KBean,service=EJB3>" (should be in state "Described", but is actually in state "** UNRESOLVED Demands 'jndi:testEAR/WBean/local-test.WLocal' **")
    Dependency "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=KBean,service=EJB3>" (should be in state "Described", but is actually in state "** UNRESOLVED Demands 'jndi:testEAR/RBean/local-test.RLocal' **")
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=KBean,service=EJB3_endpoint" is missing the following dependencies:
    Dependency "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=KBean,service=EJB3" (should be in state "Configured", but is actually in state "PreInstall")
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=RBean,service=EJB3" is missing the following dependencies:
    Dependency "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=RBean,service=EJB3>" (should be in state "Described", but is actually in state "** UNRESOLVED Demands 'jndi:testEAR/WBean/local-test.WLocal' **")
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=RBean,service=EJB3_endpoint" is missing the following dependencies:
    Dependency "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=RBean,service=EJB3" (should be in state "Configured", but is actually in state "PreInstall")
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=TBean,service=EJB3" is missing the following dependencies:
    Dependency "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=TBean,service=EJB3>" (should be in state "Described", but is actually in state "** UNRESOLVED Demands 'jndi:testEAR/WBean/local-test.WLocal' **")
    Dependency "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=TBean,service=EJB3>" (should be in state "Described", but is actually in state "** UNRESOLVED Demands 'jndi:testEAR/RBean/local-test.RLocal' **")
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=TBean,service=EJB3_endpoint" is missing the following dependencies:
    Dependency "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=TBean,service=EJB3" (should be in state "Configured", but is actually in state "PreInstall")
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=WBean,service=EJB3" is missing the following dependencies:
    Dependency "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=WBean,service=EJB3>" (should be in state "Described", but is actually in state "** UNRESOLVED Demands 'jndi:testEAR/RBean/local-test.RLocal' **")
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=WBean,service=EJB3_endpoint" is missing the following dependencies:
    Dependency "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=WBean,service=EJB3" (should be in state "Configured", but is actually in state "PreInstall")

DEPLOYMENTS IN ERROR:
  Deployment "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=WBean,service=EJB3>" is in error due to the following reason(s): ** UNRESOLVED Demands 'jndi:testEAR/RBean/local-test.RLocal' **
  Deployment "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=KBean,service=EJB3>" is in error due to the following reason(s): ** UNRESOLVED Demands 'jndi:testEAR/WBean/local-test.WLocal' **, ** UNRESOLVED Demands 'jndi:testEAR/RBean/local-test.RLocal' **
  Deployment "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=TBean,service=EJB3>" is in error due to the following reason(s): ** UNRESOLVED Demands 'jndi:testEAR/WBean/local-test.WLocal' **, ** UNRESOLVED Demands 'jndi:testEAR/RBean/local-test.RLocal' **
  Deployment "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=RBean,service=EJB3>" is in error due to the following reason(s): ** UNRESOLVED Demands 'jndi:testEAR/WBean/local-test.WLocal' **

> Regression: Unable to deploy self referencing EJB3 session bean
> ---------------------------------------------------------------
>
>                 Key: JBAS-6122
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6122
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: Fedora Linux 9, Sun JDK 1.6.0_06
>            Reporter: Radu Radutiu
>            Assignee: Carlo de Wolf
>
> The following stateless EJB which has a self reference using @EJBs() annotation deploys fine on jboss-4.2.3 but fails to deploy on jboss-5.0.0CR2. 
> package test;
> import javax.ejb.*;
> @EJBs({@EJB(name="TestSessionBean/local",beanInterface=LocalTestSession.class,beanName="TestSessionBean")})
> @Stateless(name="TestSessionBean")
> public class TestSessionBean implements LocalTestSession {
> 	public String test() {
> 		try {
> 	        InitialContext ic = new InitialContext();
> 	        LocalTestSession lc = (LocalTestSession) ic.lookup("java:comp/env/TestSessionBean/local");
> 	        System.out.println(lc.test1());
>         } catch (NamingException e) {
> 	        e.printStackTrace();
>         }
> 		return "test";
> 	}
> 	
> 	public String test1() {
> 		return "test1";
> 	}
> 	
> }
> When deploying the jar on jboss-5.0.0CR2 I get the following error:
> 09:57:19,227 WARN  [HDScanner] Failed to process changes
> org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE
>  PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> jboss.j2ee:ear=test.jar,jar=test.jar,name=TestSessionBean,service=EJB3
>  -> <UNKNOWN jboss.j2ee:ear=test.jar,jar=test.jar,name=TestSessionBean,service=EJB3>{Described:** UNRESOLVED Demands 'jndi:TestSessionBean/local-test.LocalTestSession' **}
> *** CONTEXTS IN ERROR: Name -> Error
> <UNKNOWN jboss.j2ee:ear=test.jar,jar=test.jar,name=TestSessionBean,service=EJB3> -> ** UNRESOLVED Demands 'jndi:TestSessionBean/local-test.LocalTestSession' **

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 04:51:57 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Tue, 9 Jun 2009 04:51:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-83)
 NullPointerException in Handler#getType
In-Reply-To: <2275005.1244109956457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5075943.1244537517658.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shigeru Chiba resolved JASSIST-83.
----------------------------------

    Fix Version/s: 3.11.0.GA
       Resolution: Done


> NullPointerException in Handler#getType
> ---------------------------------------
>
>                 Key: JASSIST-83
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-83
>             Project: Javassist
>          Issue Type: Bug
>         Environment: JA version 3.4, Windows Vista and JDK 1.6.0_10
>            Reporter: Hans-Joerg Adel
>            Assignee: Shigeru Chiba
>            Priority: Optional
>             Fix For: 3.11.0.GA
>
>         Attachments: Sample.java, SampleClass.java
>
>
> Hi!
> When I use ExprEditor#edit(Handler) to access a try-statement without a catch-clause I get a NullPointerException. 
> To reproduce the bug, please use this source
> /*--- (C) 1999-2008 Techniker Krankenkasse ---*/
> package samplepackage;
> import javassist.CannotCompileException;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.NotFoundException;
> import javassist.expr.ExprEditor;
> import javassist.expr.Handler;
> public class Sample {
> 	public static void main(String[] args) throws NotFoundException, CannotCompileException {
> 		ClassPool classPool = ClassPool.getDefault();
> 		CtClass ctClass = classPool.get("samplepackage.SampleClass");
> 		ctClass.instrument(new MyExprEditor());
> 	}
> 	static class MyExprEditor extends ExprEditor {
> 		@Override
> 		public void edit(Handler h) throws CannotCompileException {
> 			try {
> 				h.getType();
> 			} catch (NotFoundException e) {
> 			}
> 		}
> 	}
> }
> Stacktrace:
> Exception in thread "main" java.lang.NullPointerException
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:517)
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:499)
> 	at javassist.expr.Handler.getType(Handler.java:76)
> 	at samplepackage.Sample$MyExprEditor.edit(Sample.java:25)
> 	at javassist.expr.ExprEditor.doit(ExprEditor.java:97)
> 	at javassist.CtClassType.instrument(CtClassType.java:1224)
> 	at samplepackage.Sample.main(Sample.java:17)
> I would expect that h.getType() returns null.
> I am using JA version 3.4, Windows Vista and JDK 1.6.0_10.
> Cheers
> Ruwen
> iA Hans-Joerg Adel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 06:11:56 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Tue, 9 Jun 2009 06:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JASSIST-79) Editing
 MethodCall produces
 incorrect byte code | java.lang.VerifyError: Illegal target of jump or
 branch | goto points to invalid instruction
In-Reply-To: <25834444.1239876805355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32087675.1244542316497.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JASSIST-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471145#action_12471145 ] 

Shigeru Chiba commented on JASSIST-79:
--------------------------------------

Thank you for posting jinsi-jassist-79.tgz.  I got why the generated class file was broken.

The bytecode GOTO takes only 16bit offset.  Since your instrumented method was bigger than 64K, Javassist could not calculate a valid offset.  To fix this problem, GOTO must be replaced with GOTO_W.  Modifying Javassist to do so is not a simple task, give me some time.

> Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | goto points to invalid instruction
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-79
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-79
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>         Environment: $ java -version
> java version "1.6.0_07"
> Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
> Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)
>            Reporter: Martin Burger
>            Assignee: Shigeru Chiba
>         Attachments: jinsi-jassist-79.tgz, Parser.instrumented.class, Parser.instrumented.dump, Parser.original.class, Parser.original.dump, Parser.original.jad, Parser.original.java
>
>
> I instrument method calls in a class called org.mozilla.javascript.Parser.
> If I run (or, load) this class, a java.lang.VerifyError will be thrown:
> Exception in thread "main" java.lang.VerifyError: (class: org/mozilla/javascript/Parser, method: statementHelper signature: (Lorg/mozilla/javascript/TokenStream;)Ljava/lang/Object;) Illegal target of jump or branch
> It seems Javassist introduces a defective goto statement at position 3200 in method statementHelper:
> 3200:        goto    -29495
> Obviously, offset -29495 is an invalid opcode address.
> The corresponding Java code (excerpt):
>         switch(tt) {
>         case TokenStream.IF: {
>             skipsemi = true;
>             sourceAdd((char)ts.IF);
>             int lineno = ts.getLineno();
>             Object cond = condition(ts);
>             sourceAdd((char)ts.LC);
>             sourceAdd((char)ts.EOL);
>             Object ifTrue = statement(ts);
>             Object ifFalse = null;
>             if (ts.matchToken(ts.ELSE)) {
>                 sourceAdd((char)ts.RC);
>                 sourceAdd((char)ts.ELSE);
>                 sourceAdd((char)ts.LC);
>                 sourceAdd((char)ts.EOL);
>                 ifFalse = statement(ts);
>             }
>             sourceAdd((char)ts.RC);
>             sourceAdd((char)ts.EOL);
>             pn = nf.createIf(cond, ifTrue, ifFalse, lineno);
>             break;
>         }
>         case TokenStream.SWITCH: {
> I think the break statement is related to this defect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 06:46:57 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Tue, 9 Jun 2009 06:46:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JASSIST-67) Strange
 Exception: Register x contains wrong type
In-Reply-To: <30186178.1225447340883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27199141.1244544417016.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JASSIST-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471149#action_12471149 ] 

Shigeru Chiba commented on JASSIST-67:
--------------------------------------

This bug is that Javassist wrongly produced IINC instruction for incrementing a local variable at an index more than 8bit.  I will fix it.

> Strange Exception: Register x contains wrong type
> -------------------------------------------------
>
>                 Key: JASSIST-67
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-67
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.8.1.GA
>         Environment: windowsXP
>            Reporter: kobe valiant
>            Assignee: Shigeru Chiba
>            Priority: Blocker
>
>         ClassPool pool = new ClassPool(true);
>         CtClass ctc = pool.makeClass("my.Clazz");
>         StringBuilder sb = new StringBuilder("public void test() {");
>         for (int i = 0; i < 1000; i++) {
>         sb.append("for(int i=0; i<10; i++) {}");                  // line 1
> //      sb.append("for(int i=0; i<10; i++) {int j=i;}");        // line 2
>         }
>         sb.append("}");
>         ctc.addMethod(CtNewMethod.make(sb.toString(), ctc));
>         ctc.toClass().newInstance();
> 	
> the code above will throw an exception:
> Exception in thread "main" java.lang.VerifyError: (class: my/Clazz, method: test signature: ()V) Register 0 contains wrong type
> But if you comment the line 1 and uncomment the line 2, there will no exception at all.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 06:59:56 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Tue, 9 Jun 2009 06:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-67) Strange Exception:
 Register x contains wrong type
In-Reply-To: <30186178.1225447340883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4282632.1244545196649.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shigeru Chiba resolved JASSIST-67.
----------------------------------

    Fix Version/s: 3.11.0.GA
       Resolution: Done


> Strange Exception: Register x contains wrong type
> -------------------------------------------------
>
>                 Key: JASSIST-67
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-67
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.8.1.GA
>         Environment: windowsXP
>            Reporter: kobe valiant
>            Assignee: Shigeru Chiba
>            Priority: Blocker
>             Fix For: 3.11.0.GA
>
>
>         ClassPool pool = new ClassPool(true);
>         CtClass ctc = pool.makeClass("my.Clazz");
>         StringBuilder sb = new StringBuilder("public void test() {");
>         for (int i = 0; i < 1000; i++) {
>         sb.append("for(int i=0; i<10; i++) {}");                  // line 1
> //      sb.append("for(int i=0; i<10; i++) {int j=i;}");        // line 2
>         }
>         sb.append("}");
>         ctc.addMethod(CtNewMethod.make(sb.toString(), ctc));
>         ctc.toClass().newInstance();
> 	
> the code above will throw an exception:
> Exception in thread "main" java.lang.VerifyError: (class: my/Clazz, method: test signature: ()V) Register 0 contains wrong type
> But if you comment the line 1 and uncomment the line 2, there will no exception at all.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 07:10:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 9 Jun 2009 07:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7004) EJB3Deployer does
 not use the
 correct MC API and ends up picking irrelevant deployments
Message-ID: <19181380.1244545856566.JavaMail.jira@cloud.prod.atl2.jboss.com>

EJB3Deployer does not use the correct MC API and ends up picking irrelevant deployments
---------------------------------------------------------------------------------------

                 Key: JBAS-7004
                 URL: https://jira.jboss.org/jira/browse/JBAS-7004
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: jaikiran pai
            Assignee: jaikiran pai


EJB3Deployer currently uses the addInput(MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME); API of MC deployers and expects that it will be invoked only if the MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME attachment is available in the deployment unit. However, this is not the right API to use. This results in the EJB3Deployer being invoked for irrelevant deployments as shown here http://lists.jboss.org/pipermail/jboss-development/2009-June/014560.html

The MC forum thread explaining the API usage is here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156725

  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 07:14:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 9 Jun 2009 07:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1634) Remove
	easymock
In-Reply-To: <5508204.1243428380565.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8164124.1244546096494.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil reassigned JBMESSAGING-1634:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Remove easymock
> ---------------
>
>                 Key: JBMESSAGING-1634
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1634
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0.CR1
>
>
> There are still a load of tests using easymock.
> Including timing tests, unit tests etc.
> These should be ported so we can remove easymock

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:07:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Tue, 9 Jun 2009 08:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2409) Unable to delete
 property without value in portal admin interface
Message-ID: <15281741.1244549276551.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unable to delete property without value in portal admin interface
-----------------------------------------------------------------

                 Key: JBPORTAL-2409
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2409
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Web
    Affects Versions: 2.7.3 Final
            Reporter: Viliam Rockai
            Assignee: Chris Laprun


This bug is present in at least three places:
-Manage properties for all portals
-Properties of each portal
-Dashboards  

in these interfaces it is possible to add values with custom names. when the property is added, it's default value is blank. when a property with blank value is to be deleted (clicking on the delete icon next to the property) nothing will happen. if some value is added to the property, it can be deleted. If you delete the value of some existing property, it can't be deleted.

after clicking on delete button (page is reloaded) for property without a value, you cannot even delete properties with values until you set values to the blank fields.

excerpt from the log:
14:07:45,694 ERROR [STDERR] Jun 9, 2009 2:07:45 PM javax.faces.component.UIInput updateModel
SEVERE: /jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean
java.lang.NullPointerException
	at org.jboss.portal.faces.gui.ManagedBean.getLocalizedType(ManagedBean.java:131)
	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:85)
	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:75)
	at org.jboss.portal.core.admin.ui.PropertyBean.setValue(PropertyBean.java:108)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
.........
14:07:45,918 INFO  [lifecycle] WARNING: FacesMessage(s) have been enqueued, but may not have been displayed.
sourceId=_AdminPortletWindow:j_id132:common-manage-prop-form:prop-data-table:0:prop-value-input[severity=(ERROR 2), summary=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean), detail=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean)]



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:19:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 9 Jun 2009 08:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1643) Ordering Group
 incorrect handling on Consumer close
In-Reply-To: <2086391.1244526116865.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26671400.1244549996648.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao closed JBMESSAGING-1643.
-----------------------------------

    Resolution: Done


> Ordering Group incorrect handling on Consumer close
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1643
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1643
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: all platform
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> On session close, all unacknowledged messages will be cancelled. For ordering group messages, if messages are cancelled, it will be redelivered first.
> But currently if the message is cancelled, the message is released from the ordering group control, making the second message being delivered. That's broken.
> The reason for the wrong order of delivery:
> 1. msg A is delivered and commited. then B is delivered to client.
> 2. consumer close() cause B cancelled back to queue. But it is wrongly removed from the linked list.
> 3. On next deliver, B cannot be delivered because it is not the first in the ordering group (B still an ordering group message). So C is delivered to client.
> 4. After C is committed, D is delivered to the client and committed.
> 5. then B is delivered as the whole ordering group is empty now.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:25:03 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1504) Full Journal
	Compactation
In-Reply-To: <33137475.1234453664451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4596929.1244550323889.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1504:
---------------------------------

    Priority: Critical  (was: Major)


> Full Journal Compactation
> -------------------------
>
>                 Key: JBMESSAGING-1504
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1504
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:31:22 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:31:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1636) AS 5 Admin
 Console integration
In-Reply-To: <6038052.1243518836528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1546518.1244550682745.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1636:
---------------------------------

    Fix Version/s: 2.1.0.beta
                       (was: 2.0.0.CR1)


> AS 5 Admin Console integration
> ------------------------------
>
>                 Key: JBMESSAGING-1636
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1636
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.1.0.beta
>
>
> AS 5 admin console manages JBM 1.4 by default.
> When JBoss Messaging 2 is used, we need to make sure that the admin console allows
> to manage JMS resources (through JMX or by providing a JON plug-in?)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:31:23 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1634) Remove easymock
In-Reply-To: <5508204.1243428380565.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8065421.1244550683236.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox closed JBMESSAGING-1634.
--------------------------------

    Resolution: Done


> Remove easymock
> ---------------
>
>                 Key: JBMESSAGING-1634
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1634
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0.CR1
>
>
> There are still a load of tests using easymock.
> Including timing tests, unit tests etc.
> These should be ported so we can remove easymock

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:31:23 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-340) Static selector
	queues
Message-ID: <31649357.1244550683946.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox closed JBMESSAGING-340.
-------------------------------

    Resolution: Out of Date


> Static selector queues
> ----------------------
>
>                 Key: JBMESSAGING-340
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-340
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0.CR1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> We should consider adding functionality to allow a selector to be associated with a queue in the deployment descriptor. The queue then does not accept any messages that do not match the selector. This is in addition to the standard jms functionality of specifying selectors on message consumers.
> It should give better performance in those cases where it is possible to know a selector to apply to an entire queue in advance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:31:21 2009
From: jira-events at lists.jboss.org (Dominik Pospisil (JIRA))
Date: Tue, 9 Jun 2009 08:31:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-984) JGroups can not
 parse IPV6 literals in TCPPING protocol configuration
In-Reply-To: <7188979.1242741125294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24940359.1244550681665.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Dominik Pospisil commented on JGRP-984:
---------------------------------------

yes, "::1[7810]" works but e. g.: 
 
 "3ffe:ffff:100:f101::3[7810],3ffe:ffff:100:f101::2[7810]" 
 
 does not: 
 14:21:15,754 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "3ffe:ffff:100:f101::3" 
 14:21:15,754 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "3ffe:ffff:100:f101::2"

> JGroups can not parse IPV6 literals in TCPPING protocol configuration
> ---------------------------------------------------------------------
>
>                 Key: JGRP-984
>                 URL: https://jira.jboss.org/jira/browse/JGRP-984
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.6
>            Reporter: Brian Stansberry
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> ON JBPAPP-2013 Dominik Pospisil reports the IPv6 address parsing fix in 2.4.6 doesn't handle TCPPING:
> Both
> <TCPPING initial_hosts="::1[7810],fec0::f101:21a:a0ff:fea0:d745[7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> and
> <TCPPING initial_hosts="[::1][7810],[fec0::f101:21a:a0ff:fea0:d745][7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> fails with:
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "::1"
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "fec0::f101:21a:a0ff:fea0:d745"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:31:21 2009
From: jira-events at lists.jboss.org (Dominik Pospisil (JIRA))
Date: Tue, 9 Jun 2009 08:31:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JGRP-984) JGroups can not
 parse IPV6 literals in TCPPING protocol configuration
In-Reply-To: <7188979.1242741125294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27467667.1244550682016.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Dominik Pospisil reopened JGRP-984:
-----------------------------------



> JGroups can not parse IPV6 literals in TCPPING protocol configuration
> ---------------------------------------------------------------------
>
>                 Key: JGRP-984
>                 URL: https://jira.jboss.org/jira/browse/JGRP-984
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.6
>            Reporter: Brian Stansberry
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> ON JBPAPP-2013 Dominik Pospisil reports the IPv6 address parsing fix in 2.4.6 doesn't handle TCPPING:
> Both
> <TCPPING initial_hosts="::1[7810],fec0::f101:21a:a0ff:fea0:d745[7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> and
> <TCPPING initial_hosts="[::1][7810],[fec0::f101:21a:a0ff:fea0:d745][7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> fails with:
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "::1"
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "fec0::f101:21a:a0ff:fea0:d745"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:31:22 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:31:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1427) Journal
	Cleanup
In-Reply-To: <6551971.1222785211162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8039177.1244550682231.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1427:
---------------------------------

    Priority: Critical  (was: Major)


> Journal Cleanup
> ---------------
>
>                 Key: JBMESSAGING-1427
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1427
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> If a destination is lazy, not consuming messages for a long time, the journal will grow until those messages are consumed.
> This would be a problem with DLQs or messages taking days before they are consumed.
> Since we inform the TransactionSummary on commits, we could change the journal to support multiple current-files based on configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:31:24 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:31:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1640)
 ClientSessionFactory are
 garbage collected while the sessions are used in the integration tests
In-Reply-To: <21551780.1244203796542.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31253449.1244550684251.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox closed JBMESSAGING-1640.
--------------------------------

    Resolution: Out of Date


> ClientSessionFactory are garbage collected while the sessions are used in the integration tests
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1640
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1640
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0.CR1
>
>
> The client session impl does not have a ref on the factory which was used to create it.
> In the integration-tests (e.g. ClientConsumerCloseTest),  there are a lot of:
> protected void setUp() throws Exception
> {
>    ClientSessionFactory sf = new ClientSessionFactoryImpl(new TransportConfiguration(InVMConnectorFactory.class.getName()));
>    ... 
>    session = sf.createSession(false, true, true);
>    session.createQueue(address, queue, false);
> }
> In that case, the sf variable will be GC'ed while the session field is still used which could lead to problems.
> The factory *must not* be GC'ed while it still has sessions. To prevent that in all case, we can add a reference to the factory
> in the created sessions.
> For the integration-tests, we must also ensure that the sf is properly closed by making the sf a field and call close() in the
> teardown methods.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:32:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1433) Enable
 replication for browsers
In-Reply-To: <3332141.1224406292113.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33016943.1244550776537.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1433:
---------------------------------

    Priority: Critical  (was: Major)


> Enable replication for browsers
> -------------------------------
>
>                 Key: JBMESSAGING-1433
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1433
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> Making a copy of the queue for a browser consumer doesn't work well with replication since
> When replicating the create consumer (browser) to the backup, when executed on the backup the
> backup may have different messages in its queue since been added on different threads.
> So when replicating deliveries they may not be found.
> Uncomment MultiThreadRandomFailoverTest::testM when this is complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:32:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1583) Fix message
 redistribution with replication
In-Reply-To: <28198275.1239022282568.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23620935.1244550776968.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1583:
---------------------------------

    Priority: Critical  (was: Major)


> Fix message redistribution with replication
> -------------------------------------------
>
>                 Key: JBMESSAGING-1583
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1583
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> Message redistribution in a replicated cluster is currently broken. Needs to be fixed and thoroughly tested.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:34:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1424) Provider
 strict message ordering via "ordering groups"
In-Reply-To: <25015723.1222415841133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32442056.1244550896706.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1424:
---------------------------------

    Priority: Critical  (was: Major)


> Provider strict message ordering via "ordering groups"
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1424
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1424
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> See linked task

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:34:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1602) Remove code
 duplication for queue creation
In-Reply-To: <9137314.1239981322726.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6103448.1244550896933.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox closed JBMESSAGING-1602.
--------------------------------

    Resolution: Out of Date


> Remove code duplication for queue creation
> ------------------------------------------
>
>                 Key: JBMESSAGING-1602
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1602
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0.CR1
>
>
> there should be only 1 place to create a (core) queue in JBM: MessagingServer.createQueue()
> but this code is duplicated in:
> MessagingServerImpl.doStart()
> MessagingServerImpl.deployQueues()
> MessagingServerControl.createQueue() (2 methods)
> ServerSessionImpl.doHandleCreateConsumer (temp code for queue browsing)
> All this duplicated code should be removed by making sure that MessagingServer.createQueue() handles everything.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:36:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1325) Sync a backup
 server with a live server
In-Reply-To: <2662823.1211906159940.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23346072.1244551016450.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1325:
---------------------------------

    Priority: Critical  (was: Major)


> Sync a backup server with a live server
> ---------------------------------------
>
>                 Key: JBMESSAGING-1325
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1325
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> If a live server has no backup server, should be able to bring one up while the live is running and for them to auto-sync.
> This is useful if the server has failed over to its backup, and you won't to bring up another backup for the failed over server.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:38:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-342) Functional
 tests bundled with the release should be functional
Message-ID: <25146716.1244551136747.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox closed JBMESSAGING-342.
-------------------------------

    Resolution: Rejected


> Functional tests bundled with the release should be functional
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-342
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-342
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 2.0.0.CR1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> The functional tests whose source code comes with the release should be compilable and runnable, so they can validate the release at unpacking.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:45:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1176) The Bridge
 Mbean needs refactoring
In-Reply-To: <9744544.1196863552263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16384202.1244551556985.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox closed JBMESSAGING-1176.
--------------------------------

    Resolution: Out of Date


> The Bridge Mbean needs refactoring
> ----------------------------------
>
>                 Key: JBMESSAGING-1176
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1176
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Andy Taylor
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0.CR1
>
>
> The bridge mbean also needs refactoring to be a pojo. Also we need to decide how, and if, this would work in an embedded deployment

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:49:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1400) Allow users
 to configure a system wide maximum connection limit
In-Reply-To: <8050340.1216224002198.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28706527.1244551797408.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1400:
---------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.GA)


> Allow users to configure a system wide maximum connection limit
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1400
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1400
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Jay Howell
>            Assignee: Tim Fox
>             Fix For: 2.0.0.CR1
>
>
> Many users are complaining of errors that say "Too many open files", which comes from the number of sockets open during jms processing. It's currently possible to run the system out of resources.  We currently only have control of this through the remoting/netty/mina layer.  We should have a setting in JBM that limits the number of connections systemwide, that is independent of the remoting protocol/package.  This way users wouldn't have to keep learning a new package/configuration setting each time the communications package changes in jbm.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:49:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1399) Allow users
 to configure a system wide maximum session limit
In-Reply-To: <4175115.1216223127220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28217025.1244551796957.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1399:
---------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.GA)


> Allow users to configure a system wide maximum session limit
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1399
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1399
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jay Howell
>            Assignee: Tim Fox
>             Fix For: 2.0.0.CR1
>
>
> Goal: keep external/internal clients from running the system out of resources(threads/memory).
> We currently have a problem where there is no limit to the number of sessions that can be created in the system.  It would be theoretically possible to have an external client create 1 million sessions in one connection and run the sever out of resources.   It's also possible to set the number of max sessions for an mdb high enough to run the system out of resources(threads/memory).  We need to be able to set a limit for the number of sessions for the system. 
> I've looked at other Messaging systems, like IBM MQ and it seems that other systems have the same setting. 
> We've had users naively suggest that we could implement this by using a bounded thread pool.  This seems too intrusive and too dangerous to do.  This can be done by limiting the number of sessions in the system, which seems like a much better suggestion.  This is much better than using a bounded thread pool for many reasons.  A couple of the reasons is..
> 1.  It doesn't expose the internal workings of JBM to the management console(leaky abstraction).  
> 2.  Users can understand a session limit easier than having to understand the internal thread pool implementation.
> 3.  Doesn't incur deadlocks
> 4.  Allows All clients to get back a message that says some thing like "Session limit reached".
> JBM 2.0 uses an unbounded thread pool for threads, which addresses any concern any performance difficulties with creating and destroying threads.  So now we can address the max number of threads in the system by configuring max sessions in the system.
> Setting a session limit seems to be a more reasonable approach than the bounded thread pool

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:49:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1432)
 ReceiveImmediate on consumer should check the server for messages
In-Reply-To: <2499468.1224263600985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19022517.1244551797181.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1432:
---------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.GA)


> ReceiveImmediate on consumer should check the server for messages
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1432
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1432
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Andy Taylor
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0.CR1
>
>
> When receiveImmediate() is called on a client consumer it only checks its internal buffer. It should also check with the server to make sure there are no messages in transit or waiting to be delivered. Once this is done the Queue Browser can be changed to use this instead of a timeout receive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:49:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1604) Hot deployment
 of JMS resource does not work in a replicated environment
In-Reply-To: <21890091.1240492573820.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11342995.1244551796726.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox closed JBMESSAGING-1604.
--------------------------------

    Resolution: Out of Date


> Hot deployment of JMS resource does not work in a replicated environment
> ------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1604
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1604
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0.CR1
>
>
> JBoss Messaging allow hot deployment of JMS resources (connection factories & destinations) by adding corresponding entries in jbm-jms.xml configuration file.
> However, resources deployed from this file are only deployed locally and are not replicated on the backup node (if there is one).
> The deployment code must be updated so that resources deployed by the JMSServerDeployer use a replication-aware management controls to create the resources rather than doing it directly using JMSServerManager.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 09:33:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 9 Jun 2009 09:33:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7004) EJB3Deployer does
 not use the
 correct MC API and ends up picking irrelevant deployments
In-Reply-To: <19181380.1244545856566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11286327.1244554437262.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai commented on JBAS-7004:
------------------------------------

The org.jboss.ejb3.deployers.Ejb3Deployer has been changed to use the correct MC API for setting JBossMetadata as a requirement.

> EJB3Deployer does not use the correct MC API and ends up picking irrelevant deployments
> ---------------------------------------------------------------------------------------
>
>                 Key: JBAS-7004
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7004
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> EJB3Deployer currently uses the addInput(MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME); API of MC deployers and expects that it will be invoked only if the MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME attachment is available in the deployment unit. However, this is not the right API to use. This results in the EJB3Deployer being invoked for irrelevant deployments as shown here http://lists.jboss.org/pipermail/jboss-development/2009-June/014560.html
> The MC forum thread explaining the API usage is here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156725
>   

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 09:33:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 9 Jun 2009 09:33:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7004) EJB3Deployer does
 not use the
 correct MC API and ends up picking irrelevant deployments
In-Reply-To: <19181380.1244545856566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25564762.1244554437135.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai resolved JBAS-7004.
--------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


> EJB3Deployer does not use the correct MC API and ends up picking irrelevant deployments
> ---------------------------------------------------------------------------------------
>
>                 Key: JBAS-7004
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7004
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> EJB3Deployer currently uses the addInput(MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME); API of MC deployers and expects that it will be invoked only if the MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME attachment is available in the deployment unit. However, this is not the right API to use. This results in the EJB3Deployer being invoked for irrelevant deployments as shown here http://lists.jboss.org/pipermail/jboss-development/2009-June/014560.html
> The MC forum thread explaining the API usage is here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156725
>   

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 09:35:57 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 9 Jun 2009 09:35:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7005) Logging categories
Message-ID: <4751763.1244554557239.JavaMail.jira@cloud.prod.atl2.jboss.com>

Logging categories
------------------

                 Key: JBAS-7005
                 URL: https://jira.jboss.org/jira/browse/JBAS-7005
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Logging
            Reporter: Jesper Pedersen
            Assignee: Scott Marlow
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


The jboss-log4j.xml should contain categories to limit the logging of all classes used during startup.

An example what is missing currently is

   <!-- Limit Arjuna
   <category name="com.arjuna">
      <priority value="INFO"/>
   </category>
   -->


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 09:37:57 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 9 Jun 2009 09:37:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7005) Logging categories
In-Reply-To: <4751763.1244554557239.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12168127.1244554677257.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott Marlow reassigned JBAS-7005:
----------------------------------

    Assignee: Scott Marlow  (was: Scott Marlow)


> Logging categories
> ------------------
>
>                 Key: JBAS-7005
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7005
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Jesper Pedersen
>            Assignee: Scott Marlow
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The jboss-log4j.xml should contain categories to limit the logging of all classes used during startup.
> An example what is missing currently is
>    <!-- Limit Arjuna
>    <category name="com.arjuna">
>       <priority value="INFO"/>
>    </category>
>    -->

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 10:46:57 2009
From: jira-events at lists.jboss.org (Zachary Bedell (JIRA))
Date: Tue, 9 Jun 2009 10:46:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-204) Validation errors
 in jboss_5_1.xsd (missing webservice-descriptionType)
In-Reply-To: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31750062.1244558817138.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Zachary Bedell commented on JBMETA-204:
---------------------------------------

Hmm... So then it's likely that any attempts I'm making to customize the retrieval locations via setting schemaLocation aren't actually having an effect?

At this point, I wonder if the 5.1 schemas are something that "should" be used?  I've not been able to get JBoss 5.1.0.GA to deploy an app which was working under 4.2.3.  Falling back to the 5.0 schemas (with the XML prolog in jboss.xml below) does appear to pass validation.

<jboss xmlns="http://www.jboss.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss_5_0.xsd"
       version="3.0">

The jboss.xml *does* validate when checked in an XML editor on my development machine, both with the 5_0 and 5_1 versions of the schema in the prolog (and the file otherwise unmodified).  Trying with the 5_1 fails at deployment with "xml is not well formed".  Starting up with trace level logging lists messages like the following for all of the elements in jboss.xml before it finally fails:

[RtElementHandler] startElement {http://www.jboss.com/xml/ns/javaee}jboss parent=null term=org.jboss.xb.binding.sunday.unmarshalling.ElementBinding at 2ddde6d0({http://www.jboss.com/xml/ns/javaee}jboss, type={http://www.jboss.com/xml/ns/javaee}jbossType)
[RtElementHandler] Failed to resolve class for element {http://www.jboss.com/xml/ns/javaee}jboss: com.jboss.xml.ns.javaee.JbossType

Deploying with the 5_0 schemas appears okay (I'm running into other problems further along now).  If the 5_1 schemas aren't considered "production ready" at this point, then this ticket can probably close out as is.  If they *are* supposed to be ready, then there's still an issue.  I can definitely provided additional logs and samples of the XML if that's the case.


> Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)
> -----------------------------------------------------------------------
>
>                 Key: JBMETA-204
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Zachary Bedell
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>
> An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 11:58:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 9 Jun 2009 11:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1644) Work out a
 suitable way to provide JBM examples/doc for AS 5
Message-ID: <25933843.1244563136418.JavaMail.jira@cloud.prod.atl2.jboss.com>

Work out a suitable way to provide JBM examples/doc for AS 5
------------------------------------------------------------

                 Key: JBMESSAGING-1644
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1644
             Project: JBoss Messaging
          Issue Type: Task
          Components: AS Integration
    Affects Versions: 1.4.3.GA
            Reporter: Howard Gao
            Assignee: Howard Gao
            Priority: Critical
             Fix For: 1.4.5.GA


Current AS 5 distribution kit doesn't have JBM doc/examples of the corresponding version included, that makes it very inconvenient to use JBM with AS5. Users often get confused with which version of JBM is the correct version, and where to get the resouces (docs, examples).

We have to provide a solution to that. 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 12:31:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 9 Jun 2009 12:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7006) Error starting JMS
 Destination service via AS admin console
Message-ID: <19122080.1244565116599.JavaMail.jira@cloud.prod.atl2.jboss.com>

Error starting JMS Destination service via AS admin console
-----------------------------------------------------------

                 Key: JBAS-7006
                 URL: https://jira.jboss.org/jira/browse/JBAS-7006
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMX/Web Console
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Howard Gao
            Assignee: Darran Lofthouse


To reproduce:

1. deploy a queue service in AS_home/server/all/deploy/messaging/destinations-service.xml
2. start AS : run.sh -c all
3. log in to JBoss AS Administration Console, click 'JMS Destinations' then 'Queues'. 
4. Then click the queue on the right pane. Client the 'Control' tab.
5. first click 'stop' operation, it will result in success. Then click 'start', it will fail with the following log message:

java.lang.reflect.UndeclaredThrowableException: Failed to invoke method 'start' on component 'jboss.messaging.destination:name=123456789012345,service=Queue' with parameters [].
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.invoke(KernelBusRuntimeComponentDispatcher.java:201)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:69)
        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.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java)
        at org.jboss.profileservice.management.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:64)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.invokeOperation(ManagedComponentComponent.java:159)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:482)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalArgumentException: No such context: jboss.messaging.destination:name=123456789012345,service=Queue
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:51)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.invoke(BasicKernelBus.java:92)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.invoke(KernelBusRuntimeComponentDispatcher.java:186)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:69)
        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.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java)
        at org.jboss.profileservice.management.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:64)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.invokeOperation(ManagedComponentComponent.java:159)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:482)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 18 more


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 12:31:56 2009
From: jira-events at lists.jboss.org (Robert Wolinski (JIRA))
Date: Tue, 9 Jun 2009 12:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-5199) Exception in
 server.log during startup
In-Reply-To: <17236534.1201884010347.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7389606.1244565116845.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Robert Wolinski commented on JBAS-5199:
---------------------------------------

I have the same problem in 5.0.1. I'm trying to debug some webservice problems and this popping up in the exception stack makes troubleshooting all that more difficult.

> Exception in server.log during startup
> --------------------------------------
>
>                 Key: JBAS-5199
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5199
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  JBossAS-5.0.0.Beta3
>         Environment: windows xp; jboss 5.0.0Beta3
>            Reporter: Scott Dickerson
>         Attachments: boot.log, server.log
>
>
> 2008-02-01 11:28:19,685 DEBUG [org.jboss.mx.loading.UnifiedLoaderRepository3] Failed to update pkgs for cl=org.jboss.mx.loading.UnifiedClassLoader3 at 473fc2{ url=vfsfile:/C:/JavaTools/jboss-5.0.0.Beta3/server/test/deploy/http-invoker.sar/ ,addedOrder=20}
> java.io.FileNotFoundException: C:\JavaTools\jboss-5.0.0.Beta3\server\test\deploy\http-invoker.sar\invoker.war\WEB-INF\classes (Access is denied)
> 	at java.io.FileInputStream.open(Native Method)
> 	at java.io.FileInputStream.<init>(FileInputStream.java:106)
> 	at org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:105)
> 	at java.net.URL.openStream(URL.java:1007)
>         ....
> (see attached server.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 12:58:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 9 Jun 2009 12:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-988) Add API to manipulate
 JChannelFactory stacks member
Message-ID: <22228859.1244566736540.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add API to manipulate JChannelFactory stacks member
---------------------------------------------------

                 Key: JGRP-988
                 URL: https://jira.jboss.org/jira/browse/JGRP-988
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Brian Stansberry
            Assignee: Bela Ban
             Fix For: 2.6.11


I'd like to see the following methods added to JChannelFactory to go along with the existing getConfig and removeConfig.  These will allow the JBoss AS-specific subclass to update the contents of the "stacks" member in response to updates from management tools like the embedded console or Jopr:

public boolean addConfig(String stack_name, String config, boolean replace) {
   boolean added = replace;
   if(replace) {
       stacks.put(st_name, val);
       if(log.isTraceEnabled())
           log.trace("added config '" + st_name + "'");
    }
    else {
        if(!stacks.containsKey(st_name)) {
            stacks.put(st_name, val);
            added = true;
            if(log.isTraceEnabled())
               log.trace("added config '" + st_name + "'");
    }
    else {
         if(log.isTraceEnabled())
           log.trace("didn't add config '" + st_name + " because one of the same name already existed");
    }

    return added;
}

public Set<String> getConfigNames() {
   return Collections.unmodifiableSet(stacks.keySet());
}

Bela, I've assigned this to you to get your feedback on it, but I'd be happy to do it. Just assign back to me.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 13:09:09 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 9 Jun 2009 13:09:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7007) Upgrade AS TestSuite
	to JUnit 4.6
Message-ID: <24691632.1244567349279.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade AS TestSuite to JUnit 4.6
---------------------------------

                 Key: JBAS-7007
                 URL: https://jira.jboss.org/jira/browse/JBAS-7007
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-6.0.0.Alpha1


AS TestSuite is still in the dark ages of JUnit 3.x...upgrade time

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 13:43:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 9 Jun 2009 13:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6962)
 org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
In-Reply-To: <994948.1242838745393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33379167.1244569436552.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-6962:
---------------------------------


The generated SQL looks fine except for the differences in the conditional AND expressions so looks like an adjustment to the test case as done in JBAS-5497.  

> org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
> ----------------------------------------------------------------------
>
>                 Key: JBAS-6962
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6962
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: TEST-org.jboss.test.cmp2.commerce.CompleteUnitTestCase.xml
>
>
> With IBM JDK 1.6 the test testJBossQL fails with this message:
> Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> junit.framework.AssertionFailedError: Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> 	at org.jboss.test.cmp2.commerce.QueryTest.testJBossQL(QueryTest.java:169)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)
> It's strange that with IBM 1.6 the failure does not happen in that test, but in different - testEJBQL:
> expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> junit.framework.ComparisonFailure: expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> 	at org.jboss.test.cmp2.commerce.QueryTest.testEJBQL(QueryTest.java:329)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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:193)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Tue Jun  9 13:46:08 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 9 Jun 2009 13:46:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-988) Add API to
 manipulate JChannelFactory stacks member
In-Reply-To: <22228859.1244566736540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1925425.1244569568958.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban commented on JGRP-988:
-------------------------------

I have no objection, but I'm questioning in general whether we should trash JChannelFactory. It is IMO pretty useless, new apps inject channels anyway, and that mechanism is external.
Can't we move this entire class into JBoss AS ? I'll definitely trash it in 3.0...

> Add API to manipulate JChannelFactory stacks member
> ---------------------------------------------------
>
>                 Key: JGRP-988
>                 URL: https://jira.jboss.org/jira/browse/JGRP-988
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Brian Stansberry
>            Assignee: Bela Ban
>             Fix For: 2.6.11
>
>
> I'd like to see the following methods added to JChannelFactory to go along with the existing getConfig and removeConfig.  These will allow the JBoss AS-specific subclass to update the contents of the "stacks" member in response to updates from management tools like the embedded console or Jopr:
> public boolean addConfig(String stack_name, String config, boolean replace) {
>    boolean added = replace;
>    if(replace) {
>        stacks.put(st_name, val);
>        if(log.isTraceEnabled())
>            log.trace("added config '" + st_name + "'");
>     }
>     else {
>         if(!stacks.containsKey(st_name)) {
>             stacks.put(st_name, val);
>             added = true;
>             if(log.isTraceEnabled())
>                log.trace("added config '" + st_name + "'");
>     }
>     else {
>          if(log.isTraceEnabled())
>            log.trace("didn't add config '" + st_name + " because one of the same name already existed");
>     }
>     return added;
> }
> public Set<String> getConfigNames() {
>    return Collections.unmodifiableSet(stacks.keySet());
> }
> Bela, I've assigned this to you to get your feedback on it, but I'd be happy to do it. Just assign back to me.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 13:55:56 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 9 Jun 2009 13:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-353) contribute xsd to xml
 catalog (xsd dependent on runtime)
Message-ID: <22572021.1244570156492.JavaMail.jira@cloud.prod.atl2.jboss.com>

contribute xsd to xml catalog (xsd dependent on runtime)
--------------------------------------------------------

                 Key: GPD-353
                 URL: https://jira.jboss.org/jira/browse/GPD-353
             Project: JBoss jBPM GPD
          Issue Type: Task
          Components: jpdl
            Reporter: Koen Aers
            Assignee: Koen Aers
             Fix For: jBPM jPDL Designer 4.0.0.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 14:23:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 9 Jun 2009 14:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JGRP-988) Add API to manipulate
 JChannelFactory stacks member
In-Reply-To: <22228859.1244566736540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21941429.1244571836857.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry reassigned JGRP-988:
-------------------------------------

    Assignee: Brian Stansberry  (was: Bela Ban)


I'd prefer to have the class in AS. The problem is JBC and JBM use the JGroups version, so the AS is forced to subclass it to be compatible.

I'll think about it a bit; if you aren't going to ever change this class I could simply move the entire impl into the AS class and almost treat the JGroups class as an interface. Save the JGroups project the hassle of making changes, putting them in releases etc.

> Add API to manipulate JChannelFactory stacks member
> ---------------------------------------------------
>
>                 Key: JGRP-988
>                 URL: https://jira.jboss.org/jira/browse/JGRP-988
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.6.11
>
>
> I'd like to see the following methods added to JChannelFactory to go along with the existing getConfig and removeConfig.  These will allow the JBoss AS-specific subclass to update the contents of the "stacks" member in response to updates from management tools like the embedded console or Jopr:
> public boolean addConfig(String stack_name, String config, boolean replace) {
>    boolean added = replace;
>    if(replace) {
>        stacks.put(st_name, val);
>        if(log.isTraceEnabled())
>            log.trace("added config '" + st_name + "'");
>     }
>     else {
>         if(!stacks.containsKey(st_name)) {
>             stacks.put(st_name, val);
>             added = true;
>             if(log.isTraceEnabled())
>                log.trace("added config '" + st_name + "'");
>     }
>     else {
>          if(log.isTraceEnabled())
>            log.trace("didn't add config '" + st_name + " because one of the same name already existed");
>     }
>     return added;
> }
> public Set<String> getConfigNames() {
>    return Collections.unmodifiableSet(stacks.keySet());
> }
> Bela, I've assigned this to you to get your feedback on it, but I'd be happy to do it. Just assign back to me.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 14:37:56 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 9 Jun 2009 14:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-289) Process Debugger
In-Reply-To: <24199398.1231385044241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1807252.1244572676590.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Koen Aers updated GPD-289:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)


as predicted, move to post GA

> Process Debugger
> ----------------
>
>                 Key: GPD-289
>                 URL: https://jira.jboss.org/jira/browse/GPD-289
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> It should be possible to add breakpoints to the process definition. When the process is run from a unit test in debugging mode, the execution should stop at the appropriate breakpoint, giving the developer the possibility to inspect process variables, etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 15:36:56 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 9 Jun 2009 15:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7005) Logging categories
In-Reply-To: <4751763.1244554557239.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5735511.1244576216614.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott Marlow resolved JBAS-7005.
--------------------------------

    Resolution: Done


Added additional category limits.  

This impacts what users have to do when enabling trace/debug (by changing the root logger).  To enable trace/debug for any of the classes covered by the category limits, they will also need to change the category limit to allow trace/debug.

> Logging categories
> ------------------
>
>                 Key: JBAS-7005
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7005
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Jesper Pedersen
>            Assignee: Scott Marlow
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The jboss-log4j.xml should contain categories to limit the logging of all classes used during startup.
> An example what is missing currently is
>    <!-- Limit Arjuna
>    <category name="com.arjuna">
>       <priority value="INFO"/>
>    </category>
>    -->

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 16:43:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 9 Jun 2009 16:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCLUSTER-237) Improve
 ClusterChooserInterceptor exception messages
Message-ID: <31712902.1244580236721.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve ClusterChooserInterceptor exception messages
----------------------------------------------------

                 Key: JBCLUSTER-237
                 URL: https://jira.jboss.org/jira/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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 17:29:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 9 Jun 2009 17:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32536589.1244582996640.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry resolved JBAS-6808.
------------------------------------

    Resolution: Done


> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 18:29:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 9 Jun 2009 18:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-988) Add API to
 manipulate JChannelFactory stacks member
In-Reply-To: <22228859.1244566736540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13415995.1244586596440.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry commented on JGRP-988:
---------------------------------------

Sorry; that last comment was totally off-base. JBC uses the ChannelFactory interface, not the JChannelFactory class. I have a memory of needing to subclass for some reason, but perhaps I'm wrong; maybe the AS version just started off as a minor extension that has now grown so large it shouldn't be a subclass. I'll keep poking.

> Add API to manipulate JChannelFactory stacks member
> ---------------------------------------------------
>
>                 Key: JGRP-988
>                 URL: https://jira.jboss.org/jira/browse/JGRP-988
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.6.11
>
>
> I'd like to see the following methods added to JChannelFactory to go along with the existing getConfig and removeConfig.  These will allow the JBoss AS-specific subclass to update the contents of the "stacks" member in response to updates from management tools like the embedded console or Jopr:
> public boolean addConfig(String stack_name, String config, boolean replace) {
>    boolean added = replace;
>    if(replace) {
>        stacks.put(st_name, val);
>        if(log.isTraceEnabled())
>            log.trace("added config '" + st_name + "'");
>     }
>     else {
>         if(!stacks.containsKey(st_name)) {
>             stacks.put(st_name, val);
>             added = true;
>             if(log.isTraceEnabled())
>                log.trace("added config '" + st_name + "'");
>     }
>     else {
>          if(log.isTraceEnabled())
>            log.trace("didn't add config '" + st_name + " because one of the same name already existed");
>     }
>     return added;
> }
> public Set<String> getConfigNames() {
>    return Collections.unmodifiableSet(stacks.keySet());
> }
> Bela, I've assigned this to you to get your feedback on it, but I'd be happy to do it. Just assign back to me.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 22:13:07 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 9 Jun 2009 22:13:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6982) unable to connect
 to Profile Service remotely using EJB remote interface
In-Reply-To: <33034814.1243442816774.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29146894.1244599987101.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-6982.
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Resolution: Done


The required user was javaduke password = anotherduke, so I added admin user with password admin with the Adminstrator role as well. The org.jboss.test.profileservice.testsecure.ProfileServiceUnitTestCase which validates secured access via the ejbs.

> unable to connect to Profile Service remotely using EJB remote interface
> ------------------------------------------------------------------------
>
>                 Key: JBAS-6982
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6982
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The non-EJB remote interface is working, with the exception of the various class loading exceptions. The EJB interface is not, due to an authentication failure, but I think it used to work.
> Here's the log output showing me doing the JNDI lookup of the EJB proxies:
> DEBUG 27-05 12:40:03,988 (RemoteProfileServiceConnectionProvider.java:doConnect:90)  -Connecting to Profile Service via remote JNDI using env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:03,988 (AbstractProfileServiceConnectionProvider.java:createInitialContext:74)  -Creating JNDI InitialContext with env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:04,004 (Logger.java:debug:228)  -Using ThreadLocal: false
> DEBUG 27-05 12:40:04,035 (AbstractProfileServiceConnectionProvider.java:createInitialContext:83)  -Created JNDI InitialContext [javax.naming.InitialContext at 1ccb029].
> DEBUG 27-05 12:40:04,035 (Logger.java:debug:228)  -createSocket, hostAddr: /127.0.0.1, port: 1099, localAddr: null, localPort: 0, timeout: 0
> DEBUG 27-05 12:40:04,191 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureProfileService/remote
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Encrypted Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -removed SocketClientInvoker[3820e, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -Created Proxy of type $Proxy1 for EJB3 Business Interface: org.jboss.profileservice.spi.ProfileService
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureManagementView/remote
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -removed SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Created Proxy of type $Proxy3 for EJB3 Business Interface: org.jboss.deployers.spi.management.ManagementView
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureDeploymentManager/remote
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -removed SocketClientInvoker[12940b3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Created Proxy of type $Proxy5 for EJB3 Business Interface: org.jboss.deployers.spi.management.deploy.DeploymentManager
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Couldn't handle invocation directly within org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8: Current invocation "public abstract boolean org.jboss.deployers.spi.management.ManagementView.load()" is not eligible for direct handling by org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Received invocation request to method org.jboss.deployers.spi.management.ManagementView: org.jboss.deployers.spi.management.ManagementView.load(); using hash: -657996635075089079
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -removed SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] disconnecting ...
> And here's the "EJBAccessException: Caller unauthorized" that occurs when I call load() on the ManagementView proxy:
> Exception in thread "main" javax.ejb.EJBAccessException: Caller unauthorized
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:199)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         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:524)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 22:27:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 9 Jun 2009 22:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6979)
 org.jboss.dependency.spi.ControllerState class (from jboss-dependency.jar)
 required by remote Profile Service client calling
 ManagementView.getDeployment()
In-Reply-To: <28592167.1243393316467.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19416717.1244600876708.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-6979.
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Resolution: Rejected


No, jboss-dependency.jar is required as its a dependency of the  org.jboss.integration:jboss-profileservice-spi (jboss-profileservice-spi.jar) spi:

    <dependency>
      <groupId>org.jboss.microcontainer</groupId>
      <artifactId>jboss-dependency</artifactId>
    </dependency>


> org.jboss.dependency.spi.ControllerState class (from jboss-dependency.jar) required by remote Profile Service client calling ManagementView.getDeployment()
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6979
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6979
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> I'm assuming this class should not be required by a remote client.
> Here's the stack trace:
> 2009-05-26 22:41:31,357 WARN  [InventoryManager.discovery-1] (rhq.core.pc.inventory.InventoryManager)- Failure during discovery for [EJB3 JAR] Resources - failed after 156 ms.
> java.lang.Exception: Discovery component invocation failed.
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:248)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NoClassDefFoundError: org/jboss/dependency/spi/ControllerState
> 	at org.jboss.profileservice.spi.types.ControllerStateMetaType.<init>(ControllerStateMetaType.java:53)
> 	at org.jboss.profileservice.spi.types.ControllerStateMetaType.<clinit>(ControllerStateMetaType.java:49)
> 	at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> 	at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> 	at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> 	at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
> 	at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
> 	at java.lang.reflect.Field.getLong(Field.java:528)
> 	at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1614)
> 	at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
> 	at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:413)
> 	at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.managed.plugins.DefaultFieldsImpl.readObject(DefaultFieldsImpl.java:378)
> 	at sun.reflect.GeneratedMethodAccessor380.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.managed.plugins.ManagedPropertyImpl.readVersion1(ManagedPropertyImpl.java:652)
> 	at org.jboss.managed.plugins.ManagedPropertyImpl.readObject(ManagedPropertyImpl.java:626)
> 	at sun.reflect.GeneratedMethodAccessor379.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at AOPProxy$1.getDeployment(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.AbstractManagedDeploymentDiscoveryComponent.discoverResources(AbstractManagedDeploymentDiscoveryComponent.java:86)
> 	at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
> 	... 5 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.dependency.spi.ControllerState
> 	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 org.rhq.core.pc.plugin.ChildFirstPluginClassLoader.loadClass(ChildFirstPluginClassLoader.java:68)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> 	... 87 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 22:42:56 2009
From: jira-events at lists.jboss.org (Tihomir Surdilovic (JIRA))
Date: Tue, 9 Jun 2009 22:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAOP-45) callfield pointcut
Message-ID: <17519801.1244601776646.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tihomir Surdilovic reassigned JBAOP-45:
---------------------------------------

    Assignee:     (was: Tihomir Surdilovic)


> callfield pointcut
> ------------------
>
>                 Key: JBAOP-45
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-45
>             Project: JBoss AOP
>          Issue Type: Feature Request
>    Affects Versions: 2.1.0.CR1
>            Reporter: Bill Burke
>             Fix For: 2.2.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 22:42:57 2009
From: jira-events at lists.jboss.org (Tihomir Surdilovic (JIRA))
Date: Tue, 9 Jun 2009 22:42:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAOP-576) Optimize
 recalculating caller chains when adding a binding
In-Reply-To: <7732724.1211215679818.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6241403.1244601777130.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tihomir Surdilovic reassigned JBAOP-576:
----------------------------------------

    Assignee:     (was: Tihomir Surdilovic)


> Optimize recalculating caller chains when adding a binding
> ----------------------------------------------------------
>
>                 Key: JBAOP-576
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-576
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>             Fix For: 2.2.0.GA
>
>
> Should just need to recalculate that particular binding similar to what was done for JBAOP-575

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 22:42:56 2009
From: jira-events at lists.jboss.org (Tihomir Surdilovic (JIRA))
Date: Tue, 9 Jun 2009 22:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAOP-577) Optimize adding
 aspect bindings to instance advisors
In-Reply-To: <8024818.1211215859308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18610424.1244601776870.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tihomir Surdilovic reassigned JBAOP-577:
----------------------------------------

    Assignee:     (was: Tihomir Surdilovic)


> Optimize adding aspect bindings to instance advisors
> ----------------------------------------------------
>
>                 Key: JBAOP-577
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-577
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>             Fix For: 2.2.0.GA
>
>
> With the changes from JBAOP-575, it seems that the chains are still fully calculated when woven with GeneratedAdvisorInstrumentor if added for an instance. Run org.jboss.test.aop.dynamicgenadvisor.DynamicTester.testSimpleInstanceUsingDomainForMethod() and testInstanceUsingDomainForMethod() in a debugger to see what I mean

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 23:05:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 9 Jun 2009 23:05:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6980)
 "ClassNotFoundException:
 org.jboss.aop.instrument.Untransformable" occurs when
 ManagementView.getComponentsForType(<MBean:WebApplication>) is called from
 a remote client
In-Reply-To: <15938916.1243426198456.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17054095.1244603157055.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-6980.
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Resolution: Done


The CtClass.toClass call is outside of the profile service layer, so there is not anything I can do here. 

> "ClassNotFoundException: org.jboss.aop.instrument.Untransformable" occurs when ManagementView.getComponentsForType(<MBean:WebApplication>) is called from a remote client
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6980
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6980
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Note, this occurs even though I have jboss-aop-client.jar, which contains org.jboss.aop.instrument.Untransformable, in my client's classpath. Here's the stack trace:
> 2009-05-27 07:54:31,035 WARN  [InventoryManager.discovery-1] (rhq.core.pc.inventory.InventoryManager)- Failure during discovery for [Embedded Web Application Context] Resources - failed after 250 ms.
> java.lang.Exception: Discovery component invocation failed.
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:248)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.IllegalStateException: org.jboss.remoting.InvocationFailureException: Unable to perform invocation; nested exception is: 
> 	java.lang.RuntimeException: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:160)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:141)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.getWebApplicationComponents(WebApplicationContextDiscoveryComponent.java:182)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.discoverResources(WebApplicationContextDiscoveryComponent.java:90)
> 	at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
> 	... 5 more
> Caused by: org.jboss.remoting.InvocationFailureException: Unable to perform invocation; nested exception is: 
> 	java.lang.RuntimeException: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:142)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:891)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	... 12 more
> Caused by: java.lang.RuntimeException: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at org.jboss.aop.proxy.MarshalledInterfaceProxy.readResolve(MarshalledInterfaceProxy.java:76)
> 	at sun.reflect.GeneratedMethodAccessor973.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:141)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.getWebApplicationComponents(WebApplicationContextDiscoveryComponent.java:182)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.discoverResources(WebApplicationContextDiscoveryComponent.java:90)
> 	at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	... 19 more
> Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at javassist.ClassPool.toClass(ClassPool.java:1035)
> 	at javassist.scopedpool.ScopedClassPool.toClass(ScopedClassPool.java:306)
> 	at javassist.CtClass.toClass(CtClass.java:1094)
> 	at org.jboss.aop.instrument.TransformerCommon$ToClassAction$2.toClass(TransformerCommon.java:331)
> 	at org.jboss.aop.instrument.TransformerCommon.toClass(TransformerCommon.java:139)
> 	at org.jboss.aop.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:126)
> 	at org.jboss.aop.proxy.ProxyFactory.createInterfaceProxy(ProxyFactory.java:96)
> 	at org.jboss.aop.proxy.MarshalledInterfaceProxy.readResolve(MarshalledInterfaceProxy.java:72)
> 	at sun.reflect.GeneratedMethodAccessor973.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	... 19 more
> Caused by: java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
> 	at sun.reflect.GeneratedMethodAccessor974.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at javassist.ClassPool.toClass2(ClassPool.java:1047)
> 	at javassist.ClassPool.toClass(ClassPool.java:1029)
> 	... 82 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.aop.instrument.Untransformable
> 	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)
> 	... 89 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 01:10:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 01:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6984) trying to remotely
 retrieve
 statistic properties (e.g. rollbackCount) from MCBean:JTA managed
 components results in "ClassNotFoundException:
 com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
In-Reply-To: <11628190.1243511107980.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16274441.1244610656808.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark commented on JBAS-6984:
-------------------------------------

A new release of jboss-managed is needed to address JBMAN-86, and JBMAN-87

> trying to remotely retrieve statistic properties (e.g. rollbackCount) from MCBean:JTA managed components results in "ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6984
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6984
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>
> 2009-05-28 07:40:01,544 ERROR [ResourceContainer.invoker.daemon-364] (org.rhq.plugins.jbossas5.ApplicationServerComponent)- Failed to obtain metric 'MCBean|JTA|*|rollbackCount'.
> java.lang.IllegalStateException: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:160)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
> 	at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
> 	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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> 	at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1462)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1312)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	... 11 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 01:09:37 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 01:09:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-86) ManagedObjectImpl
 annotations should not be serialized
Message-ID: <27322704.1244610577440.JavaMail.jira@cloud.prod.atl2.jboss.com>

ManagedObjectImpl annotations should not be serialized
------------------------------------------------------

                 Key: JBMAN-86
                 URL: https://jira.jboss.org/jira/browse/JBMAN-86
             Project: JBoss Managed
          Issue Type: Bug
          Components: managedobject
    Affects Versions: JBossMan.2.1.1.Beta2
            Reporter: Scott M Stark
            Assignee: Scott M Stark


The annotations associated with ManagedObjectImpl should not be serialized as they can contain server side objects

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 01:10:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 01:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-87) DefaultFieldsImpl
 should not serialize annotations
Message-ID: <6682940.1244610656615.JavaMail.jira@cloud.prod.atl2.jboss.com>

DefaultFieldsImpl should not serialize annotations
--------------------------------------------------

                 Key: JBMAN-87
                 URL: https://jira.jboss.org/jira/browse/JBMAN-87
             Project: JBoss Managed
          Issue Type: Bug
          Components: managedobject
    Affects Versions: JBossMan.2.1.1.Beta2
            Reporter: Scott M Stark
            Assignee: Scott M Stark


Fields annotations should not be serialized as they in general will reference server side objects

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 01:56:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 01:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-86) ManagedObjectImpl
 annotations should not be serialized
In-Reply-To: <27322704.1244610577440.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24625268.1244613416477.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBMAN-86.
--------------------------------

    Fix Version/s: JBossMan.2.1.1.Beta3
       Resolution: Done


> ManagedObjectImpl annotations should not be serialized
> ------------------------------------------------------
>
>                 Key: JBMAN-86
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-86
>             Project: JBoss Managed
>          Issue Type: Bug
>          Components: managedobject
>    Affects Versions: JBossMan.2.1.1.Beta2
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossMan.2.1.1.Beta3
>
>
> The annotations associated with ManagedObjectImpl should not be serialized as they can contain server side objects

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 02:20:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Wed, 10 Jun 2009 02:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMICROCONT-444) Create a
 jboss-service.xml->jboss-beans.xml migration tool
Message-ID: <14408672.1244614856430.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create a jboss-service.xml->jboss-beans.xml migration tool
----------------------------------------------------------

                 Key: JBMICROCONT-444
                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-444
             Project: JBoss Microcontainer
          Issue Type: Feature Request
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: JBossMC-2.0.x


Create a tool that converts jboss-service.xml files to jboss-beans.xml. 
This tool should at a minimum cover the most commonly used features of a jboss-service.xml file.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 02:18:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 02:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6984) trying to remotely
 retrieve
 statistic properties (e.g. rollbackCount) from MCBean:JTA managed
 components results in "ClassNotFoundException:
 com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
In-Reply-To: <11628190.1243511107980.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19236551.1244614736816.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-6984.
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Resolution: Done


jboss-managed 2.1.1.Beta3 no longer serializes the annotations that look to be causing this problem.

> trying to remotely retrieve statistic properties (e.g. rollbackCount) from MCBean:JTA managed components results in "ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6984
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6984
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> 2009-05-28 07:40:01,544 ERROR [ResourceContainer.invoker.daemon-364] (org.rhq.plugins.jbossas5.ApplicationServerComponent)- Failed to obtain metric 'MCBean|JTA|*|rollbackCount'.
> java.lang.IllegalStateException: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:160)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
> 	at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
> 	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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> 	at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1462)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1312)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	... 11 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 02:31:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 02:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-87) DefaultFieldsImpl
 should not serialize annotations
In-Reply-To: <6682940.1244610656615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12083396.1244615516442.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBMAN-87.
--------------------------------

    Fix Version/s: JBossMan.2.1.1.Beta3
       Resolution: Done


> DefaultFieldsImpl should not serialize annotations
> --------------------------------------------------
>
>                 Key: JBMAN-87
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-87
>             Project: JBoss Managed
>          Issue Type: Bug
>          Components: managedobject
>    Affects Versions: JBossMan.2.1.1.Beta2
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossMan.2.1.1.Beta3
>
>
> Fields annotations should not be serialized as they in general will reference server side objects

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 02:48:09 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 02:48:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-5452)
 ManagementView.getDeployment
 should always at least return a structural view of a deployment
In-Reply-To: <8840076.1208274234767.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17468536.1244616489014.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-5452.
---------------------------------

    Resolution: Done


For the various deployment types there is a default behavior that is creating a ManagedDeployment. Looking at the output from the 
http://localhost:8080/jmx-console/ProfileServiceDebugServlet, it looks like every deployment has a ManagedDeployment.

listDeploymentTree Results

ManagedDeployment: //localhost/
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=default, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=default, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:host=localhost,path=/,type=Manager, type=(ComponentType{type=MBean, subtype=WebApplicationManager}), compName=jboss.web:host=localhost,path=/,type=Manager, attachment: null
++++++ properties: [sessionIdLength, maxInactiveInterval, expiredSessions, entropy, sessionCounter, maxActiveSessions, className, processingTime, algorithm, processExpiresFrequency, rejectedSessions, sessionAverageAliveTime, randomFile, modelerType, duplicates, pathname, sessionMaxAliveTime, activeSessions, name, maxActive, distributable]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=jsp, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=jsp, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/, type=(ComponentType{type=MBean, subtype=WebApplication}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/, attachment: null
++++++ properties: [privileged, compilerClasspath, crossContext, swallowOutput, antiResourceLocking, caseSensitive, cookies, workDir, loader, unloadDelay, path, managedResource, objectName, servlets, tldScanTime, realm, namingContextListener, configFile, modelerType, saveConfig, stateManageable, state, eventProvider, cacheTTL, cachingAllowed, cacheObjectMaxSize, startupTime, statisticsProvider, javaVMs, manager, staticResources, override, docBase, defaultContextXml, server, startTime, defaultWebXml, deploymentDescriptor, mappingObject, parentClassLoader, processingTime, useNaming, delegate, antiJARLocking, valveObjectNames, cacheMaxSize, logger, engineName, allowLinking, children, reloadable, welcomeFiles]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=Status Servlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=Status Servlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
ManagedDeployment: //localhost/admin-console
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/admin-console,j2eeType=Servlet,name=Faces Servlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/admin-console,j2eeType=Servlet,name=Faces Servlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/admin-console, type=(ComponentType{type=MBean, subtype=WebApplication}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/admin-console, attachment: null
++++++ properties: [privileged, compilerClasspath, crossContext, swallowOutput, antiResourceLocking, caseSensitive, cookies, workDir, loader, unloadDelay, path, managedResource, objectName, servlets, tldScanTime, realm, namingContextListener, configFile, modelerType, saveConfig, stateManageable, state, eventProvider, cacheTTL, cachingAllowed, cacheObjectMaxSize, startupTime, statisticsProvider, javaVMs, manager, staticResources, override, docBase, defaultContextXml, server, startTime, defaultWebXml, deploymentDescriptor, mappingObject, parentClassLoader, processingTime, useNaming, delegate, antiJARLocking, valveObjectNames, cacheMaxSize, logger, engineName, allowLinking, children, reloadable, welcomeFiles]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/admin-console,j2eeType=Servlet,name=default, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/admin-console,j2eeType=Servlet,name=default, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/admin-console,j2eeType=Servlet,name=jsp, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/admin-console,j2eeType=Servlet,name=jsp, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:host=localhost,path=/admin-console,type=Manager, type=(ComponentType{type=MBean, subtype=WebApplicationManager}), compName=jboss.web:host=localhost,path=/admin-console,type=Manager, attachment: null
++++++ properties: [sessionIdLength, maxInactiveInterval, expiredSessions, entropy, sessionCounter, maxActiveSessions, className, processingTime, algorithm, processExpiresFrequency, rejectedSessions, sessionAverageAliveTime, randomFile, modelerType, duplicates, pathname, sessionMaxAliveTime, activeSessions, name, maxActive, distributable]
ManagedDeployment: //localhost/invoker
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=ReadOnlyJNDIFactory, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=ReadOnlyJNDIFactory, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/invoker, type=(ComponentType{type=MBean, subtype=WebApplication}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/invoker, attachment: null
++++++ properties: [privileged, compilerClasspath, crossContext, swallowOutput, antiResourceLocking, caseSensitive, cookies, workDir, loader, unloadDelay, path, managedResource, objectName, servlets, tldScanTime, realm, namingContextListener, configFile, modelerType, saveConfig, stateManageable, state, eventProvider, cacheTTL, cachingAllowed, cacheObjectMaxSize, startupTime, statisticsProvider, javaVMs, manager, staticResources, override, docBase, defaultContextXml, server, startTime, defaultWebXml, deploymentDescriptor, mappingObject, parentClassLoader, processingTime, useNaming, delegate, antiJARLocking, valveObjectNames, cacheMaxSize, logger, engineName, allowLinking, children, reloadable, welcomeFiles]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=default, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=default, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=JNDIFactory, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=JNDIFactory, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=JMXInvokerServlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=JMXInvokerServlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=EJBInvokerServlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=EJBInvokerServlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=jsp, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=jsp, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:host=localhost,path=/invoker,type=Manager, type=(ComponentType{type=MBean, subtype=WebApplicationManager}), compName=jboss.web:host=localhost,path=/invoker,type=Manager, attachment: null
++++++ properties: [sessionIdLength, maxInactiveInterval, expiredSessions, entropy, sessionCounter, maxActiveSessions, className, processingTime, algorithm, processExpiresFrequency, rejectedSessions, sessionAverageAliveTime, randomFile, modelerType, duplicates, pathname, sessionMaxAliveTime, activeSessions, name, maxActive, distributable]
ManagedDeployment: //localhost/jbossws
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=ContextServlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=ContextServlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/jbossws, type=(ComponentType{type=MBean, subtype=WebApplication}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/jbossws, attachment: null
++++++ properties: [privileged, compilerClasspath, crossContext, swallowOutput, antiResourceLocking, caseSensitive, cookies, workDir, loader, unloadDelay, path, managedResource, objectName, servlets, tldScanTime, realm, namingContextListener, configFile, modelerType, saveConfig, stateManageable, state, eventProvider, cacheTTL, cachingAllowed, cacheObjectMaxSize, startupTime, statisticsProvider, javaVMs, manager, staticResources, override, docBase, defaultContextXml, server, startTime, defaultWebXml, deploymentDescriptor, mappingObject, parentClassLoader, processingTime, useNaming, delegate, antiJARLocking, valveObjectNames, cacheMaxSize, logger, engineName, allowLinking, children, reloadable, welcomeFiles]
+++ ManagedComponent(name=jboss.web:host=localhost,path=/jbossws,type=Manager, type=(ComponentType{type=MBean, subtype=WebApplicationManager}), compName=jboss.web:host=localhost,path=/jbossws,type=Manager, attachment: null
++++++ properties: [sessionIdLength, maxInactiveInterval, expiredSessions, entropy, sessionCounter, maxActiveSessions, className, processingTime, algorithm, processExpiresFrequency, rejectedSessions, sessionAverageAliveTime, randomFile, modelerType, duplicates, pathname, sessionMaxAliveTime, activeSessions, name, maxActive, distributable]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=PortComponentLinkServlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=PortComponentLinkServlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=jsp, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=jsp, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=default, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=default, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
ManagedDeployment: //localhost/jmx-console
+++ ManagedComponent(name=jboss.web:host=localhost,path=/jmx-console,type=Manager, type=(ComponentType{type=MBean, subtype=WebApplicationManager}), compName=jboss.web:host=localhost,path=/jmx-console,type=Manager, attachment: null
++++++ properties: [sessionIdLength, maxInactiveInterval, expiredSessions, entropy, sessionCounter, maxActiveSessions, className, processingTime, algorithm, processExpiresFrequency, rejectedSessions, sessionAverageAliveTime, randomFile, modelerType, duplicates, pathname, sessionMaxAliveTime, activeSessions, name, maxActive, distributable]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/jmx-console, type=(ComponentType{type=MBean, subtype=WebApplication}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/jmx-console, attachment: null
++++++ properties: [privileged, compilerClasspath, crossContext, swallowOutput, antiResourceLocking, caseSensitive, cookies, workDir, loader, unloadDelay, path, managedResource, objectName, servlets, tldScanTime, realm, namingContextListener, configFile, modelerType, saveConfig, stateManageable, state, eventProvider, cacheTTL, cachingAllowed, cacheObjectMaxSize, startupTime, statisticsProvider, javaVMs, manager, staticResources, override, docBase, defaultContextXml, server, startTime, defaultWebXml, deploymentDescriptor, mappingObject, parentClassLoader, processingTime, useNaming, delegate, antiJARLocking, valveObjectNames, cacheMaxSize, logger, engineName, allowLinking, children, reloadable, welcomeFiles]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=DisplayOpResult, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=DisplayOpResult, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=jsp, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=jsp, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=ProfileServiceDebugServlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=ProfileServiceDebugServlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=default, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=default, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=DisplayMBeans, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=DisplayMBeans, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=InspectMBean, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=InspectMBean, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=ClusterView, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=ClusterView, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=ClusteredConsoleServlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=ClusteredConsoleServlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=HtmlAdaptor, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=HtmlAdaptor, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
ManagedDeployment: //localhost/web-console
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=default, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=default, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Create String Threshold Monitor, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Create String Threshold Monitor, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/web-console, type=(ComponentType{type=MBean, subtype=WebApplication}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/web-console, attachment: null
++++++ properties: [privileged, compilerClasspath, crossContext, swallowOutput, antiResourceLocking, caseSensitive, cookies, workDir, loader, unloadDelay, path, managedResource, objectName, servlets, tldScanTime, realm, namingContextListener, configFile, modelerType, saveConfig, stateManageable, state, eventProvider, cacheTTL, cachingAllowed, cacheObjectMaxSize, startupTime, statisticsProvider, javaVMs, manager, staticResources, override, docBase, defaultContextXml, server, startTime, defaultWebXml, deploymentDescriptor, mappingObject, parentClassLoader, processingTime, useNaming, delegate, antiJARLocking, valveObjectNames, cacheMaxSize, logger, engineName, allowLinking, children, reloadable, welcomeFiles]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 Domains and Servers, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 Domains and Servers, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=HTTP Invocation, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=HTTP Invocation, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:host=localhost,path=/web-console,type=Manager, type=(ComponentType{type=MBean, subtype=WebApplicationManager}), compName=jboss.web:host=localhost,path=/web-console,type=Manager, attachment: null
++++++ properties: [sessionIdLength, maxInactiveInterval, expiredSessions, entropy, sessionCounter, maxActiveSessions, className, processingTime, algorithm, processExpiresFrequency, rejectedSessions, sessionAverageAliveTime, randomFile, modelerType, duplicates, pathname, sessionMaxAliveTime, activeSessions, name, maxActive, distributable]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=J2EEFolder, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=J2EEFolder, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 J2EE Apps, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 J2EE Apps, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=UCLs, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=UCLs, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=SystemFolder, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=SystemFolder, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Manage Threshold Monitor, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Manage Threshold Monitor, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=MBeans, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=MBeans, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Create Threshold Monitor, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Create Threshold Monitor, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=AOPFolder, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=AOPFolder, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Clear Monitor Alerts, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Clear Monitor Alerts, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Acknowledge Active Alarms, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Acknowledge Active Alarms, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Manage Snapshot, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Manage Snapshot, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Status Servlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Status Servlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 WebModule, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 WebModule, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Manage String Threshold Monitor, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Manage String Threshold Monitor, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Create Snapshot, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Create Snapshot, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 EJBModules and EJBs, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 EJBModules and EJBs, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=MonitorsFolder, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=MonitorsFolder, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JMS Message, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JMS Message, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=jsp, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=jsp, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
ManagedDeployment: GarbageCollectorMXBeans
+++ ManagedComponent(name=java.lang:type=GarbageCollectorCopy, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.GarbageCollectorMXBean
++++++ properties: [memoryPoolNames, collectionCount, valid, name, collectionTime]
+++ ManagedComponent(name=java.lang:type=GarbageCollectorMarkSweepCompact, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.GarbageCollectorMXBean
++++++ properties: [memoryPoolNames, collectionCount, valid, name, collectionTime]
ManagedDeployment: JDK PlatformMBeans
+++ ManagedComponent(name=java.lang:type=Threading, type=(ComponentType{type=MBean, subtype=Platform}), compName=java.lang:type=Threading, attachment: java.lang.management.ThreadMXBean
++++++ properties: [daemonThreadCount, threadCount, threadContentionMonitoringSupported, totalStartedThreadCount, threadCpuTimeSupported, threadCpuTimeEnabled, currentThreadCpuTime, currentThreadUserTime, peakThreadCount, allThreadIds, currentThreadCpuTimeSupported, threadContentionMonitoringEnabled]
+++ ManagedComponent(name=java.lang:type=Memory, type=(ComponentType{type=MBean, subtype=Platform}), compName=java.lang:type=Memory, attachment: java.lang.management.MemoryMXBean
++++++ properties: [heapMemoryUsage, nonHeapMemoryUsage, verbose, objectPendingFinalizationCount]
+++ ManagedComponent(name=java.lang:type=OperatingSystem, type=(ComponentType{type=MBean, subtype=Platform}), compName=java.lang:type=OperatingSystem, attachment: java.lang.management.OperatingSystemMXBean
++++++ properties: [arch, availableProcessors, name, version]
+++ ManagedComponent(name=java.lang:type=Runtime, type=(ComponentType{type=MBean, subtype=Platform}), compName=java.lang:type=Runtime, attachment: java.lang.management.RuntimeMXBean
++++++ properties: [managementSpecVersion, bootClassPathSupported, bootClassPath, uptime, specVersion, specName, vmVersion, vmName, inputArguments, systemProperties, startTime, classPath, name, libraryPath, specVendor, vmVendor]
+++ ManagedComponent(name=java.lang:type=ClassLoading, type=(ComponentType{type=MBean, subtype=Platform}), compName=java.lang:type=ClassLoading, attachment: java.lang.management.ClassLoadingMXBean
++++++ properties: [totalLoadedClassCount, unloadedClassCount, verbose, loadedClassCount]
ManagedDeployment: MemoryManagerMXBeans
+++ ManagedComponent(name=java.lang:type=MemoryManagerCopy, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryManagerMXBean
++++++ properties: [memoryPoolNames, valid, name]
+++ ManagedComponent(name=java.lang:type=MemoryManagerCodeCacheManager, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryManagerMXBean
++++++ properties: [memoryPoolNames, valid, name]
+++ ManagedComponent(name=java.lang:type=MemoryManagerMarkSweepCompact, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryManagerMXBean
++++++ properties: [memoryPoolNames, valid, name]
ManagedDeployment: MemoryPoolMXBeans
+++ ManagedComponent(name=java.lang:type=MemoryPoolSurvivor Space, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryPoolMXBean
++++++ properties: [collectionUsageThreshold, usageThresholdCount, type, collectionUsageThresholdCount, valid, collectionUsageThresholdExceeded, usageThresholdSupported, collectionUsage, usageThreshold, usageThresholdExceeded, memoryManagerNames, usage, peakUsage, collectionUsageThresholdSupported, name]
+++ ManagedComponent(name=java.lang:type=MemoryPoolCode Cache, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryPoolMXBean
++++++ properties: [collectionUsageThreshold, usageThresholdCount, type, collectionUsageThresholdCount, valid, collectionUsageThresholdExceeded, usageThresholdSupported, collectionUsage, usageThreshold, usageThresholdExceeded, memoryManagerNames, usage, peakUsage, collectionUsageThresholdSupported, name]
+++ ManagedComponent(name=java.lang:type=MemoryPoolTenured Gen, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryPoolMXBean
++++++ properties: [collectionUsageThreshold, usageThresholdCount, type, collectionUsageThresholdCount, valid, collectionUsageThresholdExceeded, usageThresholdSupported, collectionUsage, usageThreshold, usageThresholdExceeded, memoryManagerNames, usage, peakUsage, collectionUsageThresholdSupported, name]
+++ ManagedComponent(name=java.lang:type=MemoryPoolPerm Gen, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryPoolMXBean
++++++ properties: [collectionUsageThreshold, usageThresholdCount, type, collectionUsageThresholdCount, valid, collectionUsageThresholdExceeded, usageThresholdSupported, collectionUsage, usageThreshold, usageThresholdExceeded, memoryManagerNames, usage, peakUsage, collectionUsageThresholdSupported, name]
+++ ManagedComponent(name=java.lang:type=MemoryPoolEden Space, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryPoolMXBean
++++++ properties: [collectionUsageThreshold, usageThresholdCount, type, collectionUsageThresholdCount, valid, collectionUsageThresholdExceeded, usageThresholdSupported, collectionUsage, usageThreshold, usageThresholdExceeded, memoryManagerNames, usage, peakUsage, collectionUsageThresholdSupported, name]
ManagedDeployment: ajp-127.0.0.1-8009
+++ ManagedComponent(name=jboss.web:name=ajp-127.0.0.1-8009,type=GlobalRequestProcessor, type=(ComponentType{type=MBean, subtype=WebRequestProcessor}), compName=jboss.web:name=ajp-127.0.0.1-8009,type=GlobalRequestProcessor, attachment: null
++++++ properties: [modelerType, bytesReceived, errorCount, bytesSent, processingTime, requestCount, maxTime]
+++ ManagedComponent(name=jboss.web:name=ajp-127.0.0.1-8009,type=ThreadPool, type=(ComponentType{type=MBean, subtype=WebThreadPool}), compName=jboss.web:name=ajp-127.0.0.1-8009,type=ThreadPool, attachment: null
++++++ properties: [maxThreads, backlog, currentThreadsBusy, acceptorThreadCount, threadPriority, paused, port, tcpNoDelay, soLinger, modelerType, soTimeout, daemon, running, currentThreadCount, name]
ManagedDeployment: file:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/bootstrap/aop.xml
+++ ManagedComponent(name=AOPJBossIntegration, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPJBossIntegration, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AOPClassPoolFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPClassPoolFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=aop-classloader:0.0.0$MODULE, type=(ComponentType{type=MCBean, subtype=*}), compName=aop-classloader:0.0.0$MODULE, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=aop-classloader:0.0.0, type=(ComponentType{type=MCBean, subtype=*}), compName=aop-classloader:0.0.0, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=DefaultAspectManager, type=(ComponentType{type=MCBean, subtype=*}), compName=DefaultAspectManager, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AOPClassLoaderScopingPolicy, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPClassLoaderScopingPolicy, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AspectManager, type=(ComponentType{type=MCBean, subtype=*}), compName=AspectManager, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AOPRegisterModuleCallback, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPRegisterModuleCallback, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
ManagedDeployment: file:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/bootstrap/classloader.xml
+++ ManagedComponent(name=bootstrap-classloader:0.0.0$MODULE, type=(ComponentType{type=MCBean, subtype=*}), compName=bootstrap-classloader:0.0.0$MODULE, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ClassLoaderSystem, type=(ComponentType{type=MCBean, subtype=*}), compName=ClassLoaderSystem, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ClassLoading, type=(ComponentType{type=MCBean, subtype=*}), compName=ClassLoading, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=bootstrap-classloader:0.0.0, type=(ComponentType{type=MCBean, subtype=*}), compName=bootstrap-classloader:0.0.0, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
ManagedDeployment: file:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/bootstrap/deployers.xml
+++ ManagedComponent(name=AOPXMLMetaDataParserDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPXMLMetaDataParserDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ClassLoadingMetaDataParser, type=(ComponentType{type=MCBean, subtype=*}), compName=ClassLoadingMetaDataParser, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ServiceMetaDataICF, type=(ComponentType{type=MCBean, subtype=*}), compName=ServiceMetaDataICF, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AOPAnnotationMetaDataParserDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPAnnotationMetaDataParserDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JARStructure, type=(ComponentType{type=MCBean, subtype=*}), compName=JARStructure, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=Deployers, type=(ComponentType{type=MCBean, subtype=*}), compName=Deployers, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=MainDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=MainDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ClassLoaderDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ClassLoaderDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AOPDeploymentAopMetaDataDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPDeploymentAopMetaDataDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=StructureBuilder, type=(ComponentType{type=MCBean, subtype=*}), compName=StructureBuilder, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=BeanDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=BeanDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=deployers-classloader:0.0.0, type=(ComponentType{type=MCBean, subtype=*}), compName=deployers-classloader:0.0.0, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=SARDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=SARDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=FileStructure, type=(ComponentType{type=MCBean, subtype=*}), compName=FileStructure, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=BeansDeploymentAopMetaDataDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=BeansDeploymentAopMetaDataDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=KernelDeploymentManagedObjectCreator, type=(ComponentType{type=MCBean, subtype=*}), compName=KernelDeploymentManagedObjectCreator, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=BeanMetaDataDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=BeanMetaDataDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=DeclaredStructure, type=(ComponentType{type=MCBean, subtype=*}), compName=DeclaredStructure, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=KernelDeploymentDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=KernelDeploymentDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ServiceDeploymentDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ServiceDeploymentDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ServiceDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ServiceDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=StructuralDeployers, type=(ComponentType{type=MCBean, subtype=*}), compName=StructuralDeployers, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=BeanMetaDataICF, type=(ComponentType{type=MCBean, subtype=*}), compName=BeanMetaDataICF, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JARFilter, type=(ComponentType{type=MCBean, subtype=*}), compName=JARFilter, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ClassLoadingDefaultDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ClassLoadingDefaultDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ClassLoaderClassPathDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ClassLoaderClassPathDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ClassLoaderDescribeDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ClassLoaderDescribeDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JARStructureCandidates, type=(ComponentType{type=MCBean, subtype=*}), compName=JARStructureCandidates, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AOPClassLoaderDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPClassLoaderDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ManagedObjectCreator, type=(ComponentType{type=MCBean, subtype=*}), compName=ManagedObjectCreator, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ManagedDeploymentCreator, type=(ComponentType{type=MCBean, subtype=*}), compName=ManagedDeploymentCreator, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=deployers-classloader:0.0.0$MODULE, type=(ComponentType{type=MCBean, subtype=*}), compName=deployers-classloader:0.0.0$MODULE, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ModificationTypeStructureProcessor, type=(ComponentType{type=MCBean, subtype=*}), compName=ModificationTypeStructureProcessor, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ServiceClassLoaderDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ServiceClassLoaderDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=InMemoryClassesDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=InMemoryClassesDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
ManagedDeployment: file:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/bootstrap/jmx.xml
+++ ManagedComponent(name=JMXStartStopAdvice, type=(ComponentType{type=MCBean, subtype=*}), compName=JMXStartStopAdvice, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=jboss.system:type=ServerInfo, type=(ComponentType{type=MCBean, subtype=ServerInfo}), compName=jboss.system:type=ServerInfo, attachment: org.jboss.system.server.ServerInfo
++++++ properties: [maxMemory, OSArch, hostAddress, freeMemory, activeThreadGroupCount, OSVersion, javaVMName, totalMemory, activeThreadCount, alias, hostName, javaVMVendor, javaVendor, state, availableProcessors, javaVMVersion, OSName, javaVersion]
+++ ManagedComponent(name=JMXCreateDestroyAdvice, type=(ComponentType{type=MCBean, subtype=*}), compName=JMXCreateDestroyAdvice, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=jmx-classloader:0.0.0, type=(ComponentType{type=MCBean, subtype=*}), compName=jmx-classloader:0.0.0, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JMXRegistrationAdvice, type=(ComponentType{type=MCBean, subtype=*}), compName=JMXRegistrationAdvice, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JMXStartStopAdvice$AspectBinding, type=(ComponentType{type=MCBean, subtype=*}), compName=JMXStartStopAdvice$AspectBinding, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JMXKernel, type=(ComponentType{type=MCBean, subtype=*}), compName=JMXKernel, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=jmx-classloader:0.0.0$MODULE, type=(ComponentType{type=MCBean, subtype=*}), compName=jmx-classloader:0.0.0$MODULE, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JMXRegistrationAdvice$AspectBinding, type=(ComponentType{type=MCBean, subtype=*}), compName=JMXRegistrationAdvice$AspectBinding, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=jboss.system:type=MCServer, type=(ComponentType{type=MCBean, subtype=MCServer}), compName=jboss.system:type=MCServer, attachment: org.jboss.bootstrap.impl.as.server.JBossASServerImpl
++++++ properties: [buildID, buildOS, buildNumber, startDate, config, buildDate, versionName, buildJVM, version, versionNumber]
+++ ManagedComponent(name=jboss.system:type=ServerConfig, type=(ComponentType{type=MCBean, subtype=ServerConfig}), compName=jboss.system:type=ServerConfig, attachment: org.jboss.bootstrap.impl.as.config.BasicJBossASServerConfig
++++++ properties: [serverHomeDir, serverLogLocation, udpGroup, homeUrl, serverLogDir, serverDataLocation, homeDir, serverLibraryURL, serverDataDir, bindAddress, nativeLibraryLocation, serverName, commonBaseURL, serverHomeURL, bootstrapURL, serverTempDir, serverNativeDir, partitionName, udpPort, commonLibraryURL, serverBaseDir, serverTempLocation, serverConfLocation, bootLibraryLocation, serverBaseURL]
+++ ManagedComponent(name=AspectManagerJMXRegistrar, type=(ComponentType{type=MCBean, subtype=*}), compName=AspectManagerJMXRegistrar, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JMXCreateDestroyAdvice$AspectBinding, type=(ComponentType{type=MCBean, subtype=*}), compName=JMXCreateDestroyAdvice$AspectBinding, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
ManagedDeployment: file:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/bootstrap/profile.xml
+++ ManagedComponent(name=AttachmentStore, type=(ComponentType{type=MCBean, subtype=*}), compName=AttachmentStore, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=MetaDataStructureModificationChecker$filter#1, type=(ComponentType{type=MCBean, subtype=*}), compName=MetaDataStructureModificationChecker$filter#1, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=DeploymentFilter, type=(ComponentType{type=MCBean, subtype=*}), compName=DeploymentFilter, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ComponentMapperRegistry, type=(ComponentType{type=MCBean, subtype=*}), compName=ComponentMapperRegistry, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ProfileRepositoryFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=ProfileRepositoryFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ProfileFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=ProfileFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=StructureModificationChecker, type=(ComponentType{type=MCBean, subtype=*}), compName=StructureModificationChecker, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ProfileServiceBootstrap, type=(ComponentType{type=MCBean, subtype=*}), compName=ProfileServiceBootstrap, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=BootstrapProfileFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=BootstrapProfileFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=MetaDataStructureModificationChecker, type=(ComponentType{type=MCBean, subtype=*}), compName=MetaDataStructureModificationChecker, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ProfileServicePersistenceDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ProfileServicePersistenceDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ProfileService, type=(ComponentType{type=MCBean, subtype=*}), compName=ProfileService, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=WebVisitorAttributes, type=(ComponentType{type=MCBean, subtype=*}), compName=WebVisitorAttributes, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=DefaultProfileKey, type=(ComponentType{type=MCBean, subtype=*}), compName=DefaultProfileKey, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=DefaultDeploymentRepositoryFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=DefaultDeploymentRepositoryFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ServiceDeploymentComponentMapper, type=(ComponentType{type=MCBean, subtype=*}), compName=ServiceDeploymentComponentMapper, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=SynchAdapter, type=(ComponentType{type=MCBean, subtype=*}), compName=SynchAdapter, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=StructureModCache, type=(ComponentType{type=MCBean, subtype=*}), compName=StructureModCache, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=BasicProfileFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=BasicProfileFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=KernelDeploymentComponentMapper, type=(ComponentType{type=MCBean, subtype=*}), compName=KernelDeploymentComponentMapper, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=PersistenceFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=PersistenceFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=FilteredProfileFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=FilteredProfileFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=profile-classloader:0.0.0, type=(ComponentType{type=MCBean, subtype=*}), compName=profile-classloader:0.0.0, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AttachmentsSerializer, type=(ComponentType{type=MCBean, subtype=*}), compName=AttachmentsSerializer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ProfileServiceDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ProfileServiceDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=profile-classloader:0.0.0$MODULE, type=(ComponentType{type=MCBean, subtype=*}), compName=profile-classloader:0.0.0$MODULE, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
ManagedDeployment: http-127.0.0.1-8080
+++ ManagedComponent(name=jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor, type=(ComponentType{type=MBean, subtype=WebRequestProcessor}), compName=jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor, attachment: null
++++++ properties: [modelerType, bytesReceived, errorCount, bytesSent, processingTime, requestCount, maxTime]
+++ ManagedComponent(name=jboss.web:name=http-127.0.0.1-8080,type=ThreadPool, type=(ComponentType{type=MBean, subtype=WebThreadPool}), compName=jboss.web:name=http-127.0.0.1-8080,type=ThreadPool, attachment: null
++++++ properties: [maxThreads, backlog, currentThreadsBusy, acceptorThreadCount, threadPriority, paused, port, tcpNoDelay, soLinger, modelerType, soTimeout, daemon, running, currentThreadCount, name]
ManagedDeployment: localhost
+++ ManagedComponent(name=jboss.web:host=localhost,type=Host, type=(ComponentType{type=MBean, subtype=WebHost}), compName=jboss.web:host=localhost,type=Host, attachment: null
++++++ properties: [deployOnStartup, valveNames, deployXML, realm, xmlNamespaceAware, xmlValidation, modelerType, valveObjectNames, appBase, autoDeploy, configClass, name, children, aliases, unpackWARs, managedResource]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/bindingservice.beans/
+++ ManagedComponent(name=ServiceBindingManager, type=(ComponentType{type=MCBean, subtype=ServiceBindingManager}), compName=ServiceBindingManagementObject, attachment: org.jboss.services.binding.managed.ServiceBindingManagementObject
++++++ properties: [bindingSets, state, activeBindingSetName, standardBindings, serviceBindings]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/jboss-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ROOT.war/
+++ ManagedComponent(name=ContextMO, type=(ComponentType{type=WAR, subtype=Context}), compName=null, attachment: org.jboss.web.deployers.AbstractWarDeployer$ContextMO
++++++ properties: [contextRoot]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/admin-console.war/
+++ ManagedComponent(name=ContextMO, type=(ComponentType{type=WAR, subtype=Context}), compName=null, attachment: org.jboss.web.deployers.AbstractWarDeployer$ContextMO
++++++ properties: [contextRoot]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/cache-invalidation-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ejb2-container-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ejb2-timer-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ejb3-connectors-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ejb3-container-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ejb3-interceptors-aop.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ejb3-timerservice-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/hdscanner-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/hsqldb-ds.xml
+++ ManagedComponent(name=DefaultDS, type=(ComponentType{type=DataSource, subtype=LocalTx}), compName=null, attachment: org.jboss.resource.metadata.mcf.LocalDataSourceDeploymentMetaData
++++++ properties: [valid-connection-checker-class-name, validate-on-match, connection-url, url-delimiter, connectionDestroyedCount, local-transaction, jmx-invoker-name, security-domain, max-pool-size, share-prepared-statements, interleaving, statistics-formatter, maxConnectionsInUseCount, set-tx-query-timeout, use-try-lock, type-mapping, connection-definition, idle-timeout-minutes, rar-name, check-valid-connection-sql, connection-properties, connectionCreatedCount, new-connection-sql, background-validation-millis, inUseConnectionCount, jndi-name, metadata, driver-class, min-pool-size, prepared-statement-cache-size, availableConnectionCount, exception-sorter-class-name, track-connection-by-tx, no-tx-separate-pools, use-strict-min, prefill, password, minSize, use-java-context, maxSize, stale-connection-checker-class-name, blocking-timeout-millis, config-property, poolJndiName, isSameRM-override-value, transaction-isolation, background-validation, track-statements, user-name, connectionCount, allocation-retry, query-timeout, url-selector-strategy-class-name, allocation-retry-wait-millis]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/http-invoker.sar/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/http-invoker.sar/invoker.war/
+++ ManagedComponent(name=ContextMO, type=(ComponentType{type=WAR, subtype=Context}), compName=null, attachment: org.jboss.web.deployers.AbstractWarDeployer$ContextMO
++++++ properties: [contextRoot]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jbossweb.sar/
+++ ManagedComponent(name=jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor, type=(ComponentType{type=MBean, subtype=Web}), compName=ConnectorBean-http-${jboss.bind.address}-8080MO, attachment: org.jboss.web.tomcat.service.management.ConnectorBean
++++++ properties: [bytesReceived, errorCount, mbeanNameAsString, bytesSent, state, processingTime, requestCount, maxTime]
+++ ManagedComponent(name=jboss.web:name=http-127.0.0.1-8080,type=ThreadPool, type=(ComponentType{type=MBean, subtype=Web}), compName=ThreadPool-http-${jboss.bind.address}-8080MO, attachment: org.jboss.web.tomcat.service.management.ThreadPool
++++++ properties: [maxThreads, mbeanNameAsString, currentThreadsBusy, state, threadPriority, currentThreadCount]
+++ ManagedComponent(name=jboss.web:host=127.0.0.1,type=Host, type=(ComponentType{type=MBean, subtype=Web}), compName=${jboss.bind.address}-MO, attachment: org.jboss.web.tomcat.service.management.Host
++++++ properties: [valveNames, mbeanNameAsString, state, aliases, unpackWARs]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jbossws.sar/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jbossws.sar/jbossws-management.war/
+++ ManagedComponent(name=ContextMO, type=(ComponentType{type=WAR, subtype=Context}), compName=null, attachment: org.jboss.web.deployers.AbstractWarDeployer$ContextMO
++++++ properties: [contextRoot]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jca-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jmx-console.war/
+++ ManagedComponent(name=ContextMO, type=(ComponentType{type=WAR, subtype=Context}), compName=null, attachment: org.jboss.web.deployers.AbstractWarDeployer$ContextMO
++++++ properties: [contextRoot]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jmx-invoker-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jmx-remoting.sar/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jsr88-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/legacy-invokers-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/mail-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/management/console-mgr.sar/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/management/console-mgr.sar/web-console.war/
+++ ManagedComponent(name=ContextMO, type=(ComponentType{type=WAR, subtype=Context}), compName=null, attachment: org.jboss.web.deployers.AbstractWarDeployer$ContextMO
++++++ properties: [contextRoot]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/connection-factories-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/destinations-service.xml
+++ ManagedComponent(name=/queue/ExpiryQueue, type=(ComponentType{type=JMSDestination, subtype=Queue}), compName=jboss.messaging.destination:name=ExpiryQueue,service=Queue, attachment: org.jboss.jms.server.destination.QueueServiceMO
++++++ properties: [downCacheSize, createdProgrammatically, maxSize, scheduledMessageCount, messageStatistics, securityConfig, consumerCount, JNDIName, messageCount, messageCounterHistoryDayLimit, maxDeliveryAttempts, redeliveryDelay, fullSize, messageCounter, pageSize, deliveringCount, expiryQueue, DLQ, name, clustered, serverPeer]
+++ ManagedComponent(name=/queue/DLQ, type=(ComponentType{type=JMSDestination, subtype=Queue}), compName=jboss.messaging.destination:name=DLQ,service=Queue, attachment: org.jboss.jms.server.destination.QueueServiceMO
++++++ properties: [downCacheSize, createdProgrammatically, maxSize, scheduledMessageCount, messageStatistics, securityConfig, consumerCount, JNDIName, messageCount, messageCounterHistoryDayLimit, maxDeliveryAttempts, redeliveryDelay, fullSize, messageCounter, pageSize, deliveringCount, expiryQueue, DLQ, name, clustered, serverPeer]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/hsqldb-persistence-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/jms-ds.xml
+++ ManagedComponent(name=JmsXA, type=(ComponentType{type=ConnectionFactory, subtype=Tx}), compName=null, attachment: org.jboss.resource.metadata.mcf.TxConnectionFactoryDeploymentMetaData
++++++ properties: [jndi-name, validate-on-match, metadata, connectionDestroyedCount, local-transaction, min-pool-size, availableConnectionCount, jmx-invoker-name, security-domain, max-pool-size, no-tx-separate-pools, use-strict-min, interleaving, statistics-formatter, track-connection-by-tx, prefill, minSize, use-java-context, maxSize, xa-transaction, maxConnectionsInUseCount, blocking-timeout-millis, type-mapping, config-property, connection-definition, idle-timeout-minutes, poolJndiName, isSameRM-override-value, background-validation, rar-name, connectionCount, connectionCreatedCount, xa-resource-timeout, allocation-retry, background-validation-millis, inUseConnectionCount, allocation-retry-wait-millis]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/legacy-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/messaging-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/messaging-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/remoting-bisocket-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/monitoring-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/profileservice-jboss-beans.xml
+++ ManagedComponent(name=ManagementView, type=(ComponentType{type=MCBean, subtype=*}), compName=ManagementView, attachment: org.jboss.profileservice.management.ManagementViewImpl
++++++ properties: [state]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/profileservice-secured.jar/
+++ ManagedComponent(name=SecureProfileService-metrics-instance, type=(ComponentType{type=EJB3, subtype=SLSB}), compName=SecureProfileService-metrics-instance, attachment: org.jboss.ejb3.metrics.deployer.BasicStatelessSessionInstanceMetrics
++++++ properties: [removeCount, currentSize, maxSize, createCount, availableCount]
+++ ManagedComponent(name=SecureDeploymentManager-metrics-instance, type=(ComponentType{type=EJB3, subtype=SLSB}), compName=SecureDeploymentManager-metrics-instance, attachment: org.jboss.ejb3.metrics.deployer.BasicStatelessSessionInstanceMetrics
++++++ properties: [removeCount, currentSize, maxSize, createCount, availableCount]
+++ ManagedComponent(name=SecureManagementView-metrics-instance, type=(ComponentType{type=EJB3, subtype=SLSB}), compName=SecureManagementView-metrics-instance, attachment: org.jboss.ejb3.metrics.deployer.BasicStatelessSessionInstanceMetrics
++++++ properties: [removeCount, currentSize, maxSize, createCount, availableCount]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/properties-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/remoting-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/schedule-manager-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/scheduler-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/security/security-jboss-beans.xml
+++ ManagedComponent(name=JNDIBasedSecurityRegistration, type=(ComponentType{type=MCBean, subtype=Security}), compName=JNDIBasedSecurityRegistration, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [start, demands, installs, classLoader, properties, uninstalls, related, destroy, annotations, accessMode, errorHandlingMode, constructor, create, aliasMetaData, autowireType, installCallbacks, name, beans, supplies, uninstallCallbacks, mode, bean, depends, classShortName, stop, abstract, description, underlyingValue, state, autowireCandidate, parent, children, aliases]
+++ ManagedComponent(name=XMLLoginConfig, type=(ComponentType{type=MCBean, subtype=Security}), compName=XMLLoginConfig, attachment: org.jboss.security.auth.login.XMLLoginConfig
++++++ properties: [validateDTD, state, configURL]
+++ ManagedComponent(name=JBossSecuritySubjectFactory, type=(ComponentType{type=MCBean, subtype=Security}), compName=JBossSecuritySubjectFactory, attachment: org.jboss.security.integration.JBossSecuritySubjectFactory
++++++ properties: [state, securityManagement]
+++ ManagedComponent(name=SecurityConfig, type=(ComponentType{type=MCBean, subtype=Security}), compName=SecurityConfig, attachment: org.jboss.security.plugins.SecurityConfig
++++++ properties: [loginConfig, mbeanServer, state, defaultLoginConfig]
+++ ManagedComponent(name=JNDIBasedSecurityManagement, type=(ComponentType{type=MCBean, subtype=Security}), compName=JNDIBasedSecurityManagement, attachment: org.jboss.security.integration.JNDIBasedSecurityManagement
++++++ properties: [identityTrustMgrClass, authorizationMgrClass, authenticationMgrClass, state, auditMgrClass, mappingMgrClass]
+++ ManagedComponent(name=JNDIContextEstablishment, type=(ComponentType{type=MCBean, subtype=Security}), compName=JBossSecurityJNDIContextEstablishment, attachment: org.jboss.security.integration.JNDIContextEstablishment
++++++ properties: [baseContext, factoryName, state]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/security/security-policies-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/sqlexception-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/transaction-jboss-beans.xml
+++ ManagedComponent(name=TransactionManager, type=(ComponentType{type=MCBean, subtype=JTA}), compName=TransactionManager, attachment: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
++++++ properties: [transactionManager, recoveryInetAddress, runInVMRecoveryManager, commitCount, transactionStatusManagerInetAddress, applicationRollbackCount, statisticsEnabled, rollbackCount, transactionStatusManagerPort, transactionTimeout, heuristicCount, transactionSynchronizationRegistry, objectStoreDir, runningTransactionCount, nestedTransactonCount, recoveryPort, userTransaction, resourceRollbackCount, XATerminator, socketProcessIdPort, transactionCount, propagateFullContext, state, timedoutCount]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/transaction-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/uuid-key-generator.sar/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/vfs-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/xnio-provider.jar/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/alias-deployers-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/bsh.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/clustering-deployer-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/dependency-deployers-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/directory-deployer-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/ear-deployer-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/ejb-deployer-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/ejb3.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/hibernate-deployer-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-aop-jboss5.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-jca.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-threads.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossweb.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jsr77-deployers-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/logbridge-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/messaging-definitions-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/metadata-deployer-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/seam.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/security-deployer-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/webbeans.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/xnio.deployer/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/bindingservice.beans/jboss-bindingservice.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jboss-local-jdbc.rar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jboss-local-jdbc.rar/jboss-local-jdbc.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jboss-xa-jdbc.rar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jboss-xa-jdbc.rar/jboss-xa-jdbc.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jms-ra.rar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jms-ra.rar/jms-ra.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jmx-remoting.sar/jbossas-jmx-remoting.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/mail-ra.rar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/mail-ra.rar/mail-ra.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/management/console-mgr.sar/console-mgr-classes.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/management/console-mgr.sar/jcommon.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/management/console-mgr.sar/jfreechart.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/quartz-ra.rar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/quartz-ra.rar/quartz-ra.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/xnio-provider.jar/xnio-nio.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/bsh.deployer/bsh-deployer.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/ejb3.deployer/jboss-ejb3-deployer.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/ejb3.deployer/jboss-ejb3-iiop.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-aop-jboss5.deployer/jboss-aop-aspects.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-aop-jboss5.deployer/jboss-aspect-library.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-aop-jboss5.deployer/jrockit-pluggable-instrumentor.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-aop-jboss5.deployer/pluggable-instrumentor.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-ejb3-endpoint-deployer.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-ejb3-metrics-deployer.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-jca.deployer/jboss-jca-deployer.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-threads.deployer/jboss-threads-metadata.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/FastInfoset.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/jboss-jaxb-intros.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/jbossws-common.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/jbossws-framework.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/jbossws-jboss50.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/jbossws-native-core.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/jettison.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/policy.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/wsdl4j.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/xmlsec.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/xnio.deployer/xnio-metadata.jar/


> ManagementView.getDeployment should always at least return a structural view of a deployment
> --------------------------------------------------------------------------------------------
>
>                 Key: JBAS-5452
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5452
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services, ProfileService
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently the ManagementView.getDeployment(String name, DeploymentPhase phase) api requires a deployment to have @ManagementDeployment/@ManagementObject/@ManagementComponent annotations to build any type of view of the deployment. There should be a basic structure view returned in the absence of any @ManagementObject/@ManagementComponent info. It would just be the structure view with a ManagedDeployment graph that mirrors the StructureMetaData.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Jun 10 03:11:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Wed, 10 Jun 2009 03:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Work started: (JBID-68) identity
	component in JBoss5.
In-Reply-To: <1982607.1237796302346.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25607303.1244617916538.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Work on JBID-68 started by Jeff Yu.

> identity component in JBoss5.
> -----------------------------
>
>                 Key: JBID-68
>                 URL: https://jira.jboss.org/jira/browse/JBID-68
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> quote from Tom Baeyenes:
> What we need is an automated installation to install the identity component in a naked JBoss5, That automated installation should cover at least cover proper configuration of the identity component to oracle, mysql, hsqldb and postgresql. Also we'll need automatic way of generating or obtaining the DDL scripts to create and drop the DB tables.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:49:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Wed, 10 Jun 2009 03:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-79) Write a JBossAS5
 deployer for idm config file.
In-Reply-To: <30830990.1239614137512.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21071356.1244620196688.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Yu resolved JBID-79.
-------------------------

    Resolution: Done


> Write a JBossAS5 deployer for idm config file.
> ----------------------------------------------
>
>                 Key: JBID-79
>                 URL: https://jira.jboss.org/jira/browse/JBID-79
>             Project: JBoss Identity
>          Issue Type: Task
>          Components: IDM
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> Write a JBossAS5 deployer for idm config file.
> Like, use the -idm.xml (or properties file) as a suffix to boostrap the realm.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:43:07 2009
From: jira-events at lists.jboss.org (Krashan Brahmanjara (JIRA))
Date: Wed, 10 Jun 2009 03:43:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1846) CLONE -Injected
 SessionContext became invalid after passivation
Message-ID: <27788759.1244619787592.JavaMail.jira@cloud.prod.atl2.jboss.com>

CLONE -Injected SessionContext became invalid after passivation
---------------------------------------------------------------

                 Key: EJBTHREE-1846
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1846
             Project: EJB 3.0
          Issue Type: Bug
          Components: injection
    Affects Versions: AS 4.2.2.GA
            Reporter: Krashan Brahmanjara
            Assignee: Andrew Lee Rubinger


I have SFSB with SessionContext injected as:

@Resource
private SessionContext ctx;

Some of my SFSB's methods use ctx.getBusinessObject(). After passivation and activation of bean ctx.getBusinessObject() produces NPE.
While debugging I discover that ctx is instance of org.jboss.ejb3.BaseSessionContext. In it's writeExternal() / readExternal() it loose baseContext, which is needed for getBusinessObject() invocation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:49:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Wed, 10 Jun 2009 03:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-68) identity component in
	JBoss5.
In-Reply-To: <1982607.1237796302346.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4638529.1244620196518.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Yu resolved JBID-68.
-------------------------

    Resolution: Done


> identity component in JBoss5.
> -----------------------------
>
>                 Key: JBID-68
>                 URL: https://jira.jboss.org/jira/browse/JBID-68
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> quote from Tom Baeyenes:
> What we need is an automated installation to install the identity component in a naked JBoss5, That automated installation should cover at least cover proper configuration of the identity component to oracle, mysql, hsqldb and postgresql. Also we'll need automatic way of generating or obtaining the DDL scripts to create and drop the DB tables.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:44:56 2009
From: jira-events at lists.jboss.org (Krashan Brahmanjara (JIRA))
Date: Wed, 10 Jun 2009 03:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1846) CLONE -Injected
 SessionContext became invalid after passivation
In-Reply-To: <27788759.1244619787592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20929215.1244619896505.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Krashan Brahmanjara updated EJBTHREE-1846:
------------------------------------------

          Environment: JBoss AS 5.1.0DR
          Component/s:     (was: injection)
    Affects Version/s: AS 5.0.0.CR1
                           (was: AS 4.2.2.GA)


> CLONE -Injected SessionContext became invalid after passivation
> ---------------------------------------------------------------
>
>                 Key: EJBTHREE-1846
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1846
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 5.0.0.CR1
>         Environment: JBoss AS 5.1.0DR
>            Reporter: Krashan Brahmanjara
>            Assignee: Andrew Lee Rubinger
>
> I have SFSB with SessionContext injected as:
> @Resource
> private SessionContext ctx;
> Some of my SFSB's methods use ctx.getBusinessObject(). After passivation and activation of bean ctx.getBusinessObject() produces NPE.
> While debugging I discover that ctx is instance of org.jboss.ejb3.BaseSessionContext. In it's writeExternal() / readExternal() it loose baseContext, which is needed for getBusinessObject() invocation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:59:56 2009
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Wed, 10 Jun 2009 03:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-99) Unique attributes
In-Reply-To: <3795253.1242040366371.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1213823.1244620796633.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Boleslaw Dawidowicz resolved JBID-99.
-------------------------------------

    Resolution: Done


> Unique attributes
> -----------------
>
>                 Key: JBID-99
>                 URL: https://jira.jboss.org/jira/browse/JBID-99
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Boleslaw Dawidowicz
>            Assignee: Boleslaw Dawidowicz
>             Fix For: idm-1.0.0.Beta2
>
>
> Add possibility to mark attribute as unique. This means that given the value is unique in scope of IdentityObjectType (for Users or within given GroupType). There should be an API to query single User or Group based on such attribute value. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:39:56 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-293) Enhance the graphical
	view
In-Reply-To: <5322076.1231385704002.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14270755.1244626796685.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tom Baeyens updated GPD-293:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)


indeed post ga is better.
i leave this issue in 4.0.x, but i think that if you address some of these that you should create individual issues for them

> Enhance the graphical view
> --------------------------
>
>                 Key: GPD-293
>                 URL: https://jira.jboss.org/jira/browse/GPD-293
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> - (optional) labels for transitions, events and gateways
> - labels should be movable
> - preferences pages (enable/disable nodes)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:41:57 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:41:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-226) Define a repeatable
 build for
 these plugins to be exported as a feature and as a rich client application
In-Reply-To: <23044378.1216376452176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15864680.1244626917069.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/GPD-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471375#action_12471375 ] 

Tom Baeyens commented on GPD-226:
---------------------------------

Yes, RCP should be post GA.  So I'll remove it from the title.

> Define a repeatable build for these plugins to be exported as a feature and as a rich client application
> --------------------------------------------------------------------------------------------------------
>
>                 Key: GPD-226
>                 URL: https://jira.jboss.org/jira/browse/GPD-226
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:14:57 2009
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Wed, 10 Jun 2009 05:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-73) Add a
 DisassociateGroups(User user) API in the relationshipManager
In-Reply-To: <13575914.1238569174507.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10308128.1244625297120.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Boleslaw Dawidowicz resolved JBID-73.
-------------------------------------

    Resolution: Done


> Add a DisassociateGroups(User user) API in the relationshipManager
> ------------------------------------------------------------------
>
>                 Key: JBID-73
>                 URL: https://jira.jboss.org/jira/browse/JBID-73
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM, SOARequirements
>            Reporter: Jeff Yu
>            Assignee: Boleslaw Dawidowicz
>             Fix For: idm-1.0.0.Beta1
>
>
> This is the use case from SOA-Repository Identity module.
> I had Users and Groups Object, now in the UI layer, administrator update the user's groups, in the implementation, it would delete all the existing association with groups, and then created association with the new collection of group.
> So, I want to have APIs like:
> disassociateGroups(User user): It remove all of the group association with the provided User.
> disassociateGroups(String userId): It remove all of the group association with the provided userId.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:39:56 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-292) Enhance Node
	Pluggability
In-Reply-To: <8457015.1231385523992.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27692921.1244626796516.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tom Baeyens updated GPD-292:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)


> Enhance Node Pluggability
> -------------------------
>
>                 Key: GPD-292
>                 URL: https://jira.jboss.org/jira/browse/GPD-292
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> It should be possible to add nodes by adding a jar file (containing a configuration and possibly some java classes and icons) in a well-defined location.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:23:57 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 10 Jun 2009 05:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1846) CLONE -Injected
 SessionContext became invalid after passivation
In-Reply-To: <27788759.1244619787592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28252441.1244625837172.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf reassigned EJBTHREE-1846:
---------------------------------------

    Assignee: Carlo de Wolf  (was: Andrew Lee Rubinger)


> CLONE -Injected SessionContext became invalid after passivation
> ---------------------------------------------------------------
>
>                 Key: EJBTHREE-1846
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1846
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 5.0.0.CR1
>         Environment: JBoss AS 5.1.0DR
>            Reporter: Krashan Brahmanjara
>            Assignee: Carlo de Wolf
>
> I have SFSB with SessionContext injected as:
> @Resource
> private SessionContext ctx;
> Some of my SFSB's methods use ctx.getBusinessObject(). After passivation and activation of bean ctx.getBusinessObject() produces NPE.
> While debugging I discover that ctx is instance of org.jboss.ejb3.BaseSessionContext. In it's writeExternal() / readExternal() it loose baseContext, which is needed for getBusinessObject() invocation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:45:56 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-285) Support form
 generation for the new GWT console
In-Reply-To: <1779469.1231384383996.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15372630.1244627156477.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tom Baeyens updated GPD-285:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)


form tech is pluggable.  let's first build up some experience with the current forms tech to make sure that we don't switch forms tech after you've added forms generation capabilities.

> Support form generation for the new GWT console
> -----------------------------------------------
>
>                 Key: GPD-285
>                 URL: https://jira.jboss.org/jira/browse/GPD-285
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.x
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Ideally we should be able to produce a file that respects a 'standard' for which there already exist graphical gui builders.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:47:57 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:47:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-337) image clipping
In-Reply-To: <22840615.1242894476675.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19403080.1244627277081.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tom Baeyens updated GPD-337:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)


not important.  and from what i understood, this requires research, which is not worthed.

> image clipping
> --------------
>
>                 Key: GPD-337
>                 URL: https://jira.jboss.org/jira/browse/GPD-337
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> the generated images are too large.  clipping them would be nice to have.  
> watch out with clipping the top left corner (i assume that is coordinates 0,0).  if you clip that while saving the image, then the coordinates in the process, used by the console might be affected.  
> while clipping the bottom right  corner should be possible without problem for the console.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 07:11:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 10 Jun 2009 07:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1641) Stopping
 the bridge service doesn't stop the failure handler
In-Reply-To: <31429260.1244473017316.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23335902.1244632316986.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1641:
-----------------------------------------

The simplest solution is to add a boolean flag forceStop for the failure handler threads. In bridge stop(), we set it to true. In the retry loop of the failure handler, we check the flag after each retry. If the flag is true, stop retry and returns. The thread will then stop.


> Stopping the bridge service doesn't stop the failure handler
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1641
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1641
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> when bridge is stopped via the JMX, the stop() action doesn't stop the failure handler, which will keep trying to reconnect even after bridge service has been stopped.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:46:56 2009
From: jira-events at lists.jboss.org (Krashan Brahmanjara (JIRA))
Date: Wed, 10 Jun 2009 03:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1846) CLONE -Injected
 SessionContext became invalid after passivation
In-Reply-To: <27788759.1244619787592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21341234.1244620016618.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471348#action_12471348 ] 

Krashan Brahmanjara commented on EJBTHREE-1846:
-----------------------------------------------

That problem still exist.  Code below throws NPE at ctx.getBusinessObject. 

 private @Resource SessionContext ctx;
 TestLocal testBean;

 public TestBean() {
    super();
    testBean = ctx.getBusinessObject(TestLocal.class);
  }

> CLONE -Injected SessionContext became invalid after passivation
> ---------------------------------------------------------------
>
>                 Key: EJBTHREE-1846
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1846
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 5.0.0.CR1
>         Environment: JBoss AS 5.1.0DR
>            Reporter: Krashan Brahmanjara
>            Assignee: Andrew Lee Rubinger
>
> I have SFSB with SessionContext injected as:
> @Resource
> private SessionContext ctx;
> Some of my SFSB's methods use ctx.getBusinessObject(). After passivation and activation of bean ctx.getBusinessObject() produces NPE.
> While debugging I discover that ctx is instance of org.jboss.ejb3.BaseSessionContext. In it's writeExternal() / readExternal() it loose baseContext, which is needed for getBusinessObject() invocation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 06:50:57 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 10 Jun 2009 06:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-204) Validation errors
 in jboss_5_1.xsd (missing webservice-descriptionType)
In-Reply-To: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24728855.1244631057062.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Alexey Loubyansky commented on JBMETA-204:
------------------------------------------

5_1 schemas are considered production ready. The error posted means schema binding was not resolved as it should have been, i.e. instead of using schema binding based on Java JAXB/JBossXB annotations, the schema binding was built by parsing XSD which won't work. Perhaps this is related to your attempts to modify schemaLocations and the resolution process.
Let's use user forums to continue since so far it's only a discussion. (Add the forum thread URL to this issue so I don't miss it) Thanks.

> Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)
> -----------------------------------------------------------------------
>
>                 Key: JBMETA-204
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Zachary Bedell
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>
> An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 06:12:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 10 Jun 2009 06:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1846) CLONE -Injected
 SessionContext became invalid after passivation
In-Reply-To: <27788759.1244619787592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14092312.1244628776534.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf resolved EJBTHREE-1846.
-------------------------------------

    Resolution: Cannot Reproduce Bug


StatefulSessionContextImpl is the implementation of SessionContext that is injected into the bean. When getBusinessObject is called after activation it'll reinstantiate a delegate in getDelegate referencing the container.

BaseSessionContext is a class from AS 4 and no longer in use. If you need help on AS 4 post in the forums or file a support case.

> CLONE -Injected SessionContext became invalid after passivation
> ---------------------------------------------------------------
>
>                 Key: EJBTHREE-1846
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1846
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 5.0.0.CR1
>         Environment: JBoss AS 5.1.0DR
>            Reporter: Krashan Brahmanjara
>            Assignee: Carlo de Wolf
>
> I have SFSB with SessionContext injected as:
> @Resource
> private SessionContext ctx;
> Some of my SFSB's methods use ctx.getBusinessObject(). After passivation and activation of bean ctx.getBusinessObject() produces NPE.
> While debugging I discover that ctx is instance of org.jboss.ejb3.BaseSessionContext. In it's writeExternal() / readExternal() it loose baseContext, which is needed for getBusinessObject() invocation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:30:56 2009
From: jira-events at lists.jboss.org (Krashan Brahmanjara (JIRA))
Date: Wed, 10 Jun 2009 03:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6122) Regression: Unable
 to deploy self referencing EJB3 session bean
In-Reply-To: <4298875.1224591920917.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3146678.1244619056530.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Krashan Brahmanjara commented on JBAS-6122:
-------------------------------------------

>Although this should work in AS 5.0, you should use getBusinessObject to obtain a self-reference

It also doesn't work. I got nullPointerExceptions. Any resolution?

class
public class TestBean implements TestLocal, TestRemote {
 @Resource
  SessionContext ctx;
  // @EJB
  Test2Local test2Bean;
  
  public TestBean() {
    super();
    test2Bean = ctx.getBusinessObject(TestLocal.class);
  }
}


> Regression: Unable to deploy self referencing EJB3 session bean
> ---------------------------------------------------------------
>
>                 Key: JBAS-6122
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6122
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: Fedora Linux 9, Sun JDK 1.6.0_06
>            Reporter: Radu Radutiu
>            Assignee: Carlo de Wolf
>
> The following stateless EJB which has a self reference using @EJBs() annotation deploys fine on jboss-4.2.3 but fails to deploy on jboss-5.0.0CR2. 
> package test;
> import javax.ejb.*;
> @EJBs({@EJB(name="TestSessionBean/local",beanInterface=LocalTestSession.class,beanName="TestSessionBean")})
> @Stateless(name="TestSessionBean")
> public class TestSessionBean implements LocalTestSession {
> 	public String test() {
> 		try {
> 	        InitialContext ic = new InitialContext();
> 	        LocalTestSession lc = (LocalTestSession) ic.lookup("java:comp/env/TestSessionBean/local");
> 	        System.out.println(lc.test1());
>         } catch (NamingException e) {
> 	        e.printStackTrace();
>         }
> 		return "test";
> 	}
> 	
> 	public String test1() {
> 		return "test1";
> 	}
> 	
> }
> When deploying the jar on jboss-5.0.0CR2 I get the following error:
> 09:57:19,227 WARN  [HDScanner] Failed to process changes
> org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE
>  PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> jboss.j2ee:ear=test.jar,jar=test.jar,name=TestSessionBean,service=EJB3
>  -> <UNKNOWN jboss.j2ee:ear=test.jar,jar=test.jar,name=TestSessionBean,service=EJB3>{Described:** UNRESOLVED Demands 'jndi:TestSessionBean/local-test.LocalTestSession' **}
> *** CONTEXTS IN ERROR: Name -> Error
> <UNKNOWN jboss.j2ee:ear=test.jar,jar=test.jar,name=TestSessionBean,service=EJB3> -> ** UNRESOLVED Demands 'jndi:TestSessionBean/local-test.LocalTestSession' **

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 07:50:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 10 Jun 2009 07:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMDR-56)
 AnnotatedElementMetadataLoader can
 be improved to handle DeclaredMethodSignature better
Message-ID: <4694138.1244634656561.JavaMail.jira@cloud.prod.atl2.jboss.com>

AnnotatedElementMetadataLoader can be improved to handle DeclaredMethodSignature better
---------------------------------------------------------------------------------------

                 Key: JBMDR-56
                 URL: https://jira.jboss.org/jira/browse/JBMDR-56
             Project: JBoss MetaData Repository
          Issue Type: Task
            Reporter: jaikiran pai
            Assignee: jaikiran pai


Currently the AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval for a DeclaredMethodSignature calls the findMethod which results in first getting all methods of the class and then iterating over them to find the right one. This can be improved to instead call the getDeclaredMethod on the class since the DeclaredMethodSignature has the information about which class declares the method.

Please see the referenced forum thread for details.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:54:08 2009
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Wed, 10 Jun 2009 03:54:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-106) Javadoc cleanup and
	update
In-Reply-To: <9413562.1242125158753.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11410925.1244620448531.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Boleslaw Dawidowicz resolved JBID-106.
--------------------------------------

    Resolution: Done


> Javadoc cleanup and update
> --------------------------
>
>                 Key: JBID-106
>                 URL: https://jira.jboss.org/jira/browse/JBID-106
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Boleslaw Dawidowicz
>            Assignee: Boleslaw Dawidowicz
>             Fix For: idm-1.0.0.Beta1
>
>
> Javadoc is outdated or missing in many places. Need to review all API/SPI interfaces and update it where needed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 07:50:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 10 Jun 2009 07:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMDR-56)
 AnnotatedElementMetadataLoader can
 be improved to handle DeclaredMethodSignature better
In-Reply-To: <4694138.1244634656561.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23206481.1244634657017.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai updated JBMDR-56:
------------------------------

          Component/s: Loader
    Affects Version/s: JBossMDR-2.0.1.GA


> AnnotatedElementMetadataLoader can be improved to handle DeclaredMethodSignature better
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMDR-56
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-56
>             Project: JBoss MetaData Repository
>          Issue Type: Task
>          Components: Loader
>    Affects Versions: JBossMDR-2.0.1.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> Currently the AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval for a DeclaredMethodSignature calls the findMethod which results in first getting all methods of the class and then iterating over them to find the right one. This can be improved to instead call the getDeclaredMethod on the class since the DeclaredMethodSignature has the information about which class declares the method.
> Please see the referenced forum thread for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:37:56 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-284) Create an RCP version
	of the GPD
In-Reply-To: <23528169.1231384204004.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13504324.1244626676841.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tom Baeyens updated GPD-284:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)
         Priority: Optional  (was: Major)


i agree.  post ga is better

> Create an RCP version of the GPD
> --------------------------------
>
>                 Key: GPD-284
>                 URL: https://jira.jboss.org/jira/browse/GPD-284
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>            Priority: Optional
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> Part of it is already done. The remaining chunk of work is making sure the build produces the artifacts for the different target platforms and including/enabling some standard actions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 07:20:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 10 Jun 2009 07:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1629) do not
 hard-code management cluster admin user
In-Reply-To: <18532704.1242639846429.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9966451.1244632856683.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil closed JBMESSAGING-1629.
------------------------------------

    Resolution: Done


fixed in the trunk (see changelog)

> do not hard-code management cluster admin user
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1629
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1629
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>
> management cluster admin user is hard-coded in SecurityStoreImpl and we bypass security check for it.
> instead, the user should be configurable (like the management cluster password) and a regular
> user (with "manage" permission) should be created instead.
> From SecurityStoreImpl point of view, this will remove special case to handle this cluster admin user.
> Warning about not changing the default cluster credentials will have to be moved from the SecurityStoreImpl
> to either FileConfiguration (when reading the value from the conf) or ManagementServiceImpl

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:44:07 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:44:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-226) Define a repeatable
 build for these plugins to be exported as a feature
In-Reply-To: <23044378.1216376452176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12064034.1244627047667.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tom Baeyens updated GPD-226:
----------------------------

    Summary: Define a repeatable build for these plugins to be exported as a feature  (was: Define a repeatable build for these plugins to be exported as a feature and as a rich client application)


> Define a repeatable build for these plugins to be exported as a feature
> -----------------------------------------------------------------------
>
>                 Key: GPD-226
>                 URL: https://jira.jboss.org/jira/browse/GPD-226
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 08:11:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 10 Jun 2009 08:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1645)
	Multi-threaded replication
Message-ID: <19987581.1244635916851.JavaMail.jira@cloud.prod.atl2.jboss.com>

Multi-threaded replication
--------------------------

                 Key: JBMESSAGING-1645
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1645
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
            Assignee: Tim Fox
             Fix For: 2.0.0.GA


Currently replication between live and backup node is done on a single thread. The operation is replicated, executed on backup, and when the result is returned to live, it is executed on live before the result is returned to the client (if applicable). This ensures the same ordering of state changes on live and backup but effectively makes all operation single threaded, thus reducing throughput in a clustered set-up.

Instead we should implement multi-threaded replication. If replicated operations are being executed concurrently on backup it is more tricky to ensure that state changes on any object occur in the  same order as on live but it is possible.

This is how we can do it.

For the following types of objects it is important that their state changes occur in the same order on live and backup

1) Sessions (S)
2) Queues (Q)
3) Post offices. (P)

Operations that occur on the live node are either

a) Initiated externally - e.g. an operation like send message or acknowledge coming from a client

b) Initiated internally - e.g. an asynchronous delivery, a depage, or an asynchronous message expiry from the reaper

As any of these operations are being executed they may affect the state of one or more stateful objects, e.g. a send operation might affect the state of S1, Q1, Q2, S2, and S3 (as a sent message is routed to Q1 and Q2 and immediately delivered to S2 and S3).

When the operation is replicated to the backup we must ensure that the state changes on any affected stateful objects must occur in the same order as they did on live.

To do this as the operation is executed and the state changes occur, each stateful object is locked in turn, and a sequence number is obtained from the stateful object which tells us we're the nth stateful operation on that object.

So a send operation might end up with a set of state sequences numbers:

S1(12), Q1(102), Q2(32), S2 (74), S3 (1038)

Which tells us the operation cause the 12th state change on object S1, followed by the 102nd state change on object Q1 etc.

The list of sequence numbers can be stored in a thread local as the operation is executed on live.

When the operation is executed on live we delay sending back any data to the client until we have replicate the operation to the backup and got a response that the replication has been processed.

To ensure the state changes occur in the same order on backup, when we replicate the operation we also replicate the list state sequence numbers. When the operation is executed on the backup we attempt to obtain the locks on the stateful objects.

Say we try to get the lock on object Q1, but the current sequence number of the object Q1 on the backup is 100, the attempt to get the lock will block until the 101st state change is executed since we require that operation is the 102nd state change.

By using such a technique we can ensure that state changes are obtained in the same order on live and backup but are not limited to a single thread.

In many cases the objects will be in the expected or similar sequence numbers so the replications can occur in parallel.

In case of failure of the live node, operations may block indefinitely on the backup waiting for replications to arrive for missing state changes.

For this we can timeout on the lock and reverse state changes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 07:46:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 10 Jun 2009 07:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1603) Rename
 resource MBeans and controls
In-Reply-To: <16977292.1240410748899.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11174723.1244634416518.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil reassigned JBMESSAGING-1603:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Rename resource MBeans and controls
> -----------------------------------
>
>                 Key: JBMESSAGING-1603
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1603
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0.GA
>
>
> JBM resources are managed either using JMX or JBM Core connections.
> The interfaces follow JMX standard (ending with MBean) even when JBM is not managed through JMX.
> We should rename the management interface XXXMBean to XXXControl and their implementation XXXControl to XXXControlImpl
> (e.g. the resource to manage a queue will have a QueueControl interface and a QueueControlImpl implementation)
> This will continue to work with JMX since we use the StandardMBean to create the MBean registered in the MBeanServer

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 08:23:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 10 Jun 2009 08:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1504) Full Journal
	Compactation
In-Reply-To: <33137475.1234453664451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12065666.1244636636483.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1504:
---------------------------------

               Issue Type: Task  (was: Feature Request)
    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156771
              Description: 
Let me describe how I think the compacting should work.

Let's say we have a set of files in the journal:

F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10

min files is set to 10

The current file is F6 and F7, F8, F9, F10 are unused files waiting to be used

F0, F1, F2, F3, F4, F5 are files full of data and not open any more, however, data about their contents are stored in memory.

We need a compacting thread that intermittently (say every 30 seconds) scans the set of journal files in memory.

It scans F0... F5, and when it has completed that scan, it can decide which records are no longer needed in each file.

A record is no longer needed in a file if it has already been deleted in any file F0.. F5.

Once the scanner thread has computed which records are needed and which are not, it can compute a percentage of which records in total are dead space.

E.g. the scanner might compute that 72% of the data in files F0.. .F5 are dead space.

We then have a parameter that the user can configure compactorDeadSpaceThresholdPercentage, e.g. this might have a default of 75%.

If the amount of dead space computed by the scanner >= compactorDeadSpaceThresholdPercentage, then the scanner will compact those files.

The actual compacting approach goes as follows:

The scanner knows how many new files it will need for the compacted records, let's say it needs two new files - it can get these from the unused files (e.g. F7, F8, F9 or F10) if they are available.

It then opens the old files F0..F5 loads the wanted records into memory in blocks and copies them to the new files.

When this process is finished it will end up with, say, two new files containing the compacted records.

We can then save a marker file (empty in the journal directory) which says we are starting the rename.

The old files F0..F5 then need to be renamed so they are no longer used by the journal (but can be recovered in case of a crash).

Then the two new files need to be renamed so they will be picked up by the journal.

When that process completes the marker file can be deleted.

If the server crashes after renaming the old files but before renaming the new files, then the marker file will still exist in the journal. The journal can detect this on startup, and finish the process.

This ensures the journal will still startup after such a crash.

Also the JournalFile objects also need to be updated in memory when the compact is complete.
                 Priority: Critical  (was: Major)


> Full Journal Compactation
> -------------------------
>
>                 Key: JBMESSAGING-1504
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1504
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Let me describe how I think the compacting should work.
> Let's say we have a set of files in the journal:
> F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10
> min files is set to 10
> The current file is F6 and F7, F8, F9, F10 are unused files waiting to be used
> F0, F1, F2, F3, F4, F5 are files full of data and not open any more, however, data about their contents are stored in memory.
> We need a compacting thread that intermittently (say every 30 seconds) scans the set of journal files in memory.
> It scans F0... F5, and when it has completed that scan, it can decide which records are no longer needed in each file.
> A record is no longer needed in a file if it has already been deleted in any file F0.. F5.
> Once the scanner thread has computed which records are needed and which are not, it can compute a percentage of which records in total are dead space.
> E.g. the scanner might compute that 72% of the data in files F0.. .F5 are dead space.
> We then have a parameter that the user can configure compactorDeadSpaceThresholdPercentage, e.g. this might have a default of 75%.
> If the amount of dead space computed by the scanner >= compactorDeadSpaceThresholdPercentage, then the scanner will compact those files.
> The actual compacting approach goes as follows:
> The scanner knows how many new files it will need for the compacted records, let's say it needs two new files - it can get these from the unused files (e.g. F7, F8, F9 or F10) if they are available.
> It then opens the old files F0..F5 loads the wanted records into memory in blocks and copies them to the new files.
> When this process is finished it will end up with, say, two new files containing the compacted records.
> We can then save a marker file (empty in the journal directory) which says we are starting the rename.
> The old files F0..F5 then need to be renamed so they are no longer used by the journal (but can be recovered in case of a crash).
> Then the two new files need to be renamed so they will be picked up by the journal.
> When that process completes the marker file can be deleted.
> If the server crashes after renaming the old files but before renaming the new files, then the marker file will still exist in the journal. The journal can detect this on startup, and finish the process.
> This ensures the journal will still startup after such a crash.
> Also the JournalFile objects also need to be updated in memory when the compact is complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:41:56 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-306) Self Referencing
	Connections
In-Reply-To: <6129383.1237558244506.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8601015.1244626916869.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/GPD-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471374#action_12471374 ] 

Tom Baeyens commented on GPD-306:
---------------------------------

how are users suppose to do this now ?  can that serve as a workaround ?

> Self Referencing Connections
> ----------------------------
>
>                 Key: GPD-306
>                 URL: https://jira.jboss.org/jira/browse/GPD-306
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>
> There should be a convenient way to create connections that reference the same node as source and target

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:44:07 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:44:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-226) Define a repeatable
 build for these plugins to be exported as a feature
In-Reply-To: <23044378.1216376452176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6499507.1244627047822.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/GPD-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471376#action_12471376 ] 

Tom Baeyens commented on GPD-226:
---------------------------------

what exactly does this mean ?  you already have a build, right ?

> Define a repeatable build for these plugins to be exported as a feature
> -----------------------------------------------------------------------
>
>                 Key: GPD-226
>                 URL: https://jira.jboss.org/jira/browse/GPD-226
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 08:21:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 10 Jun 2009 08:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1427) Journal
	Cleanup
In-Reply-To: <6551971.1222785211162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29087911.1244636516999.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1427:
---------------------------------

    Issue Type: Task  (was: Feature Request)
      Priority: Major  (was: Critical)


> Journal Cleanup
> ---------------
>
>                 Key: JBMESSAGING-1427
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1427
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> If a destination is lazy, not consuming messages for a long time, the journal will grow until those messages are consumed.
> This would be a problem with DLQs or messages taking days before they are consumed.
> Since we inform the TransactionSummary on commits, we could change the journal to support multiple current-files based on configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 09:55:56 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 10 Jun 2009 09:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6877) EJB3 Entity Cache
	Metrics
In-Reply-To: <13995931.1241642506748.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31109228.1244642156949.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Charles Crouch commented on JBAS-6877:
--------------------------------------

We're going to try using the generic JBossCache plugin to expose these EJB3 Entity Tree Cache metrics since there isnt anything actually specify to Entities being collected

> EJB3 Entity Cache Metrics
> -------------------------
>
>                 Key: JBAS-6877
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6877
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>            Reporter: Andrew Lee Rubinger
>            Assignee: Brian Stansberry
>             Fix For: Backlog
>
>
> These statistics must be reflected in the admin-console/Jopr.
> Split from JBAS-6624:
> EJB3 Entity Tree Cache (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache-->
> <metric property="NumberOfLocksHeld" displayType="summary"/>
>          <metric property="NumberOfNodes" displayType="summary"/>
> EJB3 Entity Tree Cache Interceptor (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache,treecache-interceptor=CacheMgmtInterceptor-->
>             <metric property="HitMissRatio" displayType="summary" units="percentage"
>                     description="Returns the hit/miss ratio for the cache. This ratio is defined as hits/(hits + misses)."/>
>             <metric property="ReadWriteRatio" displayType="summary" units="percentage"
>                     description="Returns the read/write ratio for the cache. This ratio is defined as (hits + misses)/stores."/>
>             <metric property="Hits" displayType="summary"/>
>             <metric property="Misses" displayType="summary"/>
>             <metric property="Evictions" displayType="summary"/>
>             <metric property="NumberOfLocksHeld"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="AverageWriteTime" units="milliseconds"/>
>             <metric property="TimeSinceReset" units="seconds"/>
>             <metric property="AverageReadTime" units="milliseconds"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="Stores"/>
>             <metric property="NumberOfAttributes"/>
>             <metric property="ElapsedTime" units="milliseconds"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 09:30:56 2009
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Wed, 10 Jun 2009 09:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-141) Servlet Filter
 against XSS and CSRF
Message-ID: <23720221.1244640656753.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Remy Maucherat updated JBWEB-141:
---------------------------------

    Security: Public  (was: JBoss Internal)
    Priority: Minor  (was: Major)


> Servlet Filter against XSS and CSRF
> -----------------------------------
>
>                 Key: JBWEB-141
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-141
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Marc Schoenefeld
>            Assignee: Remy Maucherat
>            Priority: Minor
>
> Cross-Site scripting and cross-site request forgery attacks are common threat to every web application. 
> So a common solution offered by the http server is helpful to raise the default protection level. 
> A servlet filter will help to  
> a) allow/block requests for a set of XSS regex patterns (per default blacklist suspicious parameter patterns, and optionally whitelist valid requests for well-known applications)  
> b) allow/block requests that fulfil the criteria for being a forged request (failing nonce compare), this will need a javascript helper on the client side, to transparently protect existing applications to provide the shared secret in the session . 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 08:21:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 10 Jun 2009 08:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1645)
	Multi-threaded replication
In-Reply-To: <19987581.1244635916851.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <343194.1244636516675.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1645:
---------------------------------

    Priority: Critical  (was: Major)


> Multi-threaded replication
> --------------------------
>
>                 Key: JBMESSAGING-1645
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1645
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Currently replication between live and backup node is done on a single thread. The operation is replicated, executed on backup, and when the result is returned to live, it is executed on live before the result is returned to the client (if applicable). This ensures the same ordering of state changes on live and backup but effectively makes all operation single threaded, thus reducing throughput in a clustered set-up.
> Instead we should implement multi-threaded replication. If replicated operations are being executed concurrently on backup it is more tricky to ensure that state changes on any object occur in the  same order as on live but it is possible.
> This is how we can do it.
> For the following types of objects it is important that their state changes occur in the same order on live and backup
> 1) Sessions (S)
> 2) Queues (Q)
> 3) Post offices. (P)
> Operations that occur on the live node are either
> a) Initiated externally - e.g. an operation like send message or acknowledge coming from a client
> b) Initiated internally - e.g. an asynchronous delivery, a depage, or an asynchronous message expiry from the reaper
> As any of these operations are being executed they may affect the state of one or more stateful objects, e.g. a send operation might affect the state of S1, Q1, Q2, S2, and S3 (as a sent message is routed to Q1 and Q2 and immediately delivered to S2 and S3).
> When the operation is replicated to the backup we must ensure that the state changes on any affected stateful objects must occur in the same order as they did on live.
> To do this as the operation is executed and the state changes occur, each stateful object is locked in turn, and a sequence number is obtained from the stateful object which tells us we're the nth stateful operation on that object.
> So a send operation might end up with a set of state sequences numbers:
> S1(12), Q1(102), Q2(32), S2 (74), S3 (1038)
> Which tells us the operation cause the 12th state change on object S1, followed by the 102nd state change on object Q1 etc.
> The list of sequence numbers can be stored in a thread local as the operation is executed on live.
> When the operation is executed on live we delay sending back any data to the client until we have replicate the operation to the backup and got a response that the replication has been processed.
> To ensure the state changes occur in the same order on backup, when we replicate the operation we also replicate the list state sequence numbers. When the operation is executed on the backup we attempt to obtain the locks on the stateful objects.
> Say we try to get the lock on object Q1, but the current sequence number of the object Q1 on the backup is 100, the attempt to get the lock will block until the 101st state change is executed since we require that operation is the 102nd state change.
> By using such a technique we can ensure that state changes are obtained in the same order on live and backup but are not limited to a single thread.
> In many cases the objects will be in the expected or similar sequence numbers so the replications can occur in parallel.
> In case of failure of the live node, operations may block indefinitely on the backup waiting for replications to arrive for missing state changes.
> For this we can timeout on the lock and reverse state changes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:31:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 10 Jun 2009 10:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1603) Rename
 resource MBeans and controls
In-Reply-To: <16977292.1240410748899.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24108308.1244644316767.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil closed JBMESSAGING-1603.
------------------------------------

    Resolution: Done


fixed in the trunk (see changelog)

> Rename resource MBeans and controls
> -----------------------------------
>
>                 Key: JBMESSAGING-1603
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1603
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> JBM resources are managed either using JMX or JBM Core connections.
> The interfaces follow JMX standard (ending with MBean) even when JBM is not managed through JMX.
> We should rename the management interface XXXMBean to XXXControl and their implementation XXXControl to XXXControlImpl
> (e.g. the resource to manage a queue will have a QueueControl interface and a QueueControlImpl implementation)
> This will continue to work with JMX since we use the StandardMBean to create the MBean registered in the MBeanServer

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:27:56 2009
From: jira-events at lists.jboss.org (Penkov Vladimir (JIRA))
Date: Wed, 10 Jun 2009 10:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2421) tomahawk doesn't
 see users's roles
Message-ID: <31888261.1244644076879.JavaMail.jira@cloud.prod.atl2.jboss.com>

tomahawk doesn't see users's roles
----------------------------------

                 Key: JBPORTAL-2421
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2421
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Security
    Affects Versions: 2.7.2 Final
            Reporter: Penkov Vladimir


Create user, give him 'User' role. 
Create jsf portlet with jsfbridge. Add to some page:

<t:commandLink ... enabledOnUserRole="User">


Authenticate as created user. Visit this page. Link will always be disabled.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 09:58:13 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 09:58:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-353) contribute xsd to xml
 catalog (xsd dependent on runtime)
In-Reply-To: <22572021.1244570156492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8416951.1244642293233.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tom Baeyens updated GPD-353:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)


> contribute xsd to xml catalog (xsd dependent on runtime)
> --------------------------------------------------------
>
>                 Key: GPD-353
>                 URL: https://jira.jboss.org/jira/browse/GPD-353
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 07:44:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 10 Jun 2009 07:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1613) Make sure
 JMSServerControl
 and MessagingControl create cf methods map to constructors
In-Reply-To: <12784878.1241164606530.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7982311.1244634296704.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil closed JBMESSAGING-1613.
------------------------------------

    Resolution: Out of Date


> Make sure JMSServerControl and MessagingControl create cf methods map to constructors
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1613
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1613
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0.GA
>
>
> Currently the create connection factory methods on the core and JMS controls seem pretty arbitrary and do not map to the cf constructors - change it so they do.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 09:53:56 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 10 Jun 2009 09:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7005) Logging categories
In-Reply-To: <4751763.1244554557239.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1077323.1244642036496.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott Marlow closed JBAS-7005.
------------------------------



I reviewed the changes with Jesper and they looked good.

> Logging categories
> ------------------
>
>                 Key: JBAS-7005
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7005
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Jesper Pedersen
>            Assignee: Scott Marlow
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The jboss-log4j.xml should contain categories to limit the logging of all classes used during startup.
> An example what is missing currently is
>    <!-- Limit Arjuna
>    <category name="com.arjuna">
>       <priority value="INFO"/>
>    </category>
>    -->

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 08:21:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 10 Jun 2009 08:21:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1504) Full Journal
	Compactation
In-Reply-To: <33137475.1234453664451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3881071.1244636517256.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1504:
---------------------------------

    Priority: Major  (was: Critical)


> Full Journal Compactation
> -------------------------
>
>                 Key: JBMESSAGING-1504
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1504
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:27:57 2009
From: jira-events at lists.jboss.org (Penkov Vladimir (JIRA))
Date: Wed, 10 Jun 2009 10:27:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2421) tomahawk
 doesn't see users's roles
In-Reply-To: <31888261.1244644076879.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33195251.1244644077477.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471449#action_12471449 ] 

Penkov Vladimir commented on JBPORTAL-2421:
-------------------------------------------

Using debug I can see that principal has role 'User'. But tomahawk doesn't see it

> tomahawk doesn't see users's roles
> ----------------------------------
>
>                 Key: JBPORTAL-2421
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2421
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Security
>    Affects Versions: 2.7.2 Final
>            Reporter: Penkov Vladimir
>
> Create user, give him 'User' role. 
> Create jsf portlet with jsfbridge. Add to some page:
> <t:commandLink ... enabledOnUserRole="User">
> Authenticate as created user. Visit this page. Link will always be disabled.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:39:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 10 Jun 2009 10:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26703280.1244644796790.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jesper Pedersen updated JBXB-206:
---------------------------------

    Attachment: jbossxb.zip


> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>         Attachments: jboss-profiler.properties, jbossxb.zip
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:39:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 10 Jun 2009 10:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-206) Performance work
Message-ID: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>

Performance work
----------------

                 Key: JBXB-206
                 URL: https://jira.jboss.org/jira/browse/JBXB-206
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Task
    Affects Versions: JBossXB-2.0.1.GA
            Reporter: Jesper Pedersen
         Attachments: jboss-profiler.properties, jbossxb.zip

I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.

Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:39:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 10 Jun 2009 10:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14353582.1244644796922.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jesper Pedersen updated JBXB-206:
---------------------------------

    Attachment: jboss-profiler.properties


> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>         Attachments: jboss-profiler.properties, jbossxb.zip
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:47:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 10 Jun 2009 10:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1318) Create
 convenient overloaded methods in core client API
In-Reply-To: <19876864.1211905249734.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12909505.1244645276594.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil closed JBMESSAGING-1318.
------------------------------------

    Resolution: Done


ClientSessionFactory now has a simple constructor and the parameters can be set before the
factory i used (similar to JMS connection.setClientID())

> Create convenient overloaded methods in core client API
> -------------------------------------------------------
>
>                 Key: JBMESSAGING-1318
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1318
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> Create convenient overloaded methods for createProducer, createCOnsumer etc. Which take default values, for ease of use.
> Also allow normal Strings to be used in API.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:51:57 2009
From: jira-events at lists.jboss.org (Penkov Vladimir (JIRA))
Date: Wed, 10 Jun 2009 10:51:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2421) tomahawk doesn't
 see users's roles
In-Reply-To: <31888261.1244644076879.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10169698.1244645517073.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Penkov Vladimir updated JBPORTAL-2421:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156827


> tomahawk doesn't see users's roles
> ----------------------------------
>
>                 Key: JBPORTAL-2421
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2421
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Security
>    Affects Versions: 2.7.2 Final
>            Reporter: Penkov Vladimir
>
> Create user, give him 'User' role. 
> Create jsf portlet with jsfbridge. Add to some page:
> <t:commandLink ... enabledOnUserRole="User">
> Authenticate as created user. Visit this page. Link will always be disabled.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:59:57 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 10 Jun 2009 10:59:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6877) EJB3 Entity Cache
	Metrics
In-Reply-To: <13995931.1241642506748.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27393695.1244645997121.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry commented on JBAS-6877:
----------------------------------------

Hibernate provides an org.hibernate.jmx.StatisticsServiceMBean which provides all sorts of information about a SessionFactory, including an org.hibernate.stat.SecondLevelCacheStatistics for each entity or collection type that is cached, plus one for each query cache region.

I'm investigating whether we register this MBean as part of SessionFactory/EntityManager deployment.

> EJB3 Entity Cache Metrics
> -------------------------
>
>                 Key: JBAS-6877
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6877
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>            Reporter: Andrew Lee Rubinger
>            Assignee: Brian Stansberry
>             Fix For: Backlog
>
>
> These statistics must be reflected in the admin-console/Jopr.
> Split from JBAS-6624:
> EJB3 Entity Tree Cache (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache-->
> <metric property="NumberOfLocksHeld" displayType="summary"/>
>          <metric property="NumberOfNodes" displayType="summary"/>
> EJB3 Entity Tree Cache Interceptor (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache,treecache-interceptor=CacheMgmtInterceptor-->
>             <metric property="HitMissRatio" displayType="summary" units="percentage"
>                     description="Returns the hit/miss ratio for the cache. This ratio is defined as hits/(hits + misses)."/>
>             <metric property="ReadWriteRatio" displayType="summary" units="percentage"
>                     description="Returns the read/write ratio for the cache. This ratio is defined as (hits + misses)/stores."/>
>             <metric property="Hits" displayType="summary"/>
>             <metric property="Misses" displayType="summary"/>
>             <metric property="Evictions" displayType="summary"/>
>             <metric property="NumberOfLocksHeld"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="AverageWriteTime" units="milliseconds"/>
>             <metric property="TimeSinceReset" units="seconds"/>
>             <metric property="AverageReadTime" units="milliseconds"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="Stores"/>
>             <metric property="NumberOfAttributes"/>
>             <metric property="ElapsedTime" units="milliseconds"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 11:17:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 10 Jun 2009 11:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16219014.1244647076636.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jesper Pedersen updated JBXB-206:
---------------------------------

    Attachment: server.log.gz


Trace log for JBossXB only

> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>         Attachments: jboss-profiler.properties, jbossxb.zip, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 11:23:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 10 Jun 2009 11:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6960) once a Topic or
 Queue has been
 stopped via the 'stop' operation, none of its operations or properties
 work, and thus it cannot be restarted using the 'start' operation
In-Reply-To: <11989891.1242832445240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <234885.1244647436632.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer commented on JBAS-6960:
------------------------------------

According to Emanuel, this will be fixed once we upgrade to a new version of the Microcontainer. He is going to coordinate this with Ales.



> once a Topic or Queue has been stopped via the 'stop' operation, none of its operations or properties work, and thus it cannot be restarted using the 'start' operation
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6960
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6960
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Ian Springer
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 11:27:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 11:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6784) Add support for JMS
 ServerPeer
 managed object to support enabling metric collection through the console
In-Reply-To: <4119905.1239740302404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26361501.1244647676738.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark reassigned JBAS-6784:
-----------------------------------

    Assignee: Scott M Stark  (was: Jason T. Greene)


> Add support for JMS ServerPeer managed object to support enabling metric collection through the console
> -------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6784
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6784
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Charles Crouch
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> See 
> https://jira.jboss.org/jira/browse/JBAS-6720?focusedCommentId=12461916#action_12461916
> https://jira.jboss.org/jira/browse/JBAS-6720?focusedCommentId=12461917#action_12461917
> for more info on why this would be a good thing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 11:33:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 10 Jun 2009 11:33:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMDR-56)
 AnnotatedElementMetadataLoader
 can be improved to handle DeclaredMethodSignature better
In-Reply-To: <4694138.1244634656561.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27888779.1244648037046.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai resolved JBMDR-56.
-------------------------------

    Fix Version/s: JBossMDR-2.2.0.Beta1
       Resolution: Done


Done in both Branch_2_0 and trunk

> AnnotatedElementMetadataLoader can be improved to handle DeclaredMethodSignature better
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMDR-56
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-56
>             Project: JBoss MetaData Repository
>          Issue Type: Task
>          Components: Loader
>    Affects Versions: JBossMDR-2.0.1.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossMDR-2.2.0.Beta1
>
>
> Currently the AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval for a DeclaredMethodSignature calls the findMethod which results in first getting all methods of the class and then iterating over them to find the right one. This can be improved to instead call the getDeclaredMethod on the class since the DeclaredMethodSignature has the information about which class declares the method.
> Please see the referenced forum thread for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 11:40:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 11:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6242) invoke() for
 "listFormattedSubPoolStatistics" ManagedOperation on datasources and
 connection factory ManagedComponents returns a MetaValue with the wrong
 MetaType
In-Reply-To: <18716075.1227550606927.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4812473.1244648456835.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-6242.
---------------------------------

    Resolution: Deferred


I'm marking this resolved with deferred status as it essentially is an issue of documenting how the managed object layer needs to be configured to use a meta mapper to enforce a consistent metatype. See the associated discussion forum thread.


> invoke() for "listFormattedSubPoolStatistics" ManagedOperation on datasources and connection factory ManagedComponents returns a MetaValue with the wrong MetaType
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6242
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6242
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBAS5 Hudson build dated 200811210604
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This is another case of the data not matching the metadata.
> operation.getReturnType() returns a MutableCompositeMetaType w/ typeName java.lang.Object. However, invoke() is returning a SimpleMetaType.STRING (with value e.g. "Sub Pool Statistics: \nSub Pool Count: 0\n------------------------------------------------------\n"). 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 11:40:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 11:40:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6242) invoke() for
 "listFormattedSubPoolStatistics" ManagedOperation on datasources and
 connection factory ManagedComponents returns a MetaValue with the wrong
 MetaType
In-Reply-To: <18716075.1227550606927.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21541782.1244648457047.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark updated JBAS-6242:
--------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236776


> invoke() for "listFormattedSubPoolStatistics" ManagedOperation on datasources and connection factory ManagedComponents returns a MetaValue with the wrong MetaType
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6242
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6242
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBAS5 Hudson build dated 200811210604
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This is another case of the data not matching the metadata.
> operation.getReturnType() returns a MutableCompositeMetaType w/ typeName java.lang.Object. However, invoke() is returning a SimpleMetaType.STRING (with value e.g. "Sub Pool Statistics: \nSub Pool Count: 0\n------------------------------------------------------\n"). 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 12:03:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 10 Jun 2009 12:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
Message-ID: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>

expose a ManagedObject for EJB3 Entity Beans
--------------------------------------------

                 Key: JBAS-7008
                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Andrew Lee Rubinger
            Priority: Minor


This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 12:07:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 10 Jun 2009 12:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25796535.1244650076748.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-7008:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 12:35:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 12:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-191) JAXPDeployer
 should set the setXIncludeAware on the DocumentBuilderFactory
Message-ID: <29577087.1244651756490.JavaMail.jira@cloud.prod.atl2.jboss.com>

JAXPDeployer should set the setXIncludeAware on the DocumentBuilderFactory
--------------------------------------------------------------------------

                 Key: JBDEPLOY-191
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-191
             Project: JBoss Deployers
          Issue Type: Feature Request
          Components: deployer
            Reporter: Anil Saldhana


    Set state of XInclude processing.

    If XInclude markup is found in the document instance, should it be processed as specified in XML Inclusions (XInclude) Version 1.0. (http://www.w3.org/TR/xinclude/)

    XInclude processing defaults to false.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 12:35:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 10 Jun 2009 12:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31054214.1244651756668.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger commented on JBAS-7008:
-------------------------------------------

What do we need exposed?  Any desired behaviour should be reflected in:

http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/testsuite/src/main/org/jboss/test/profileservice/test/Ejb3MetricsUnitTestCase.java

> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:01:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 10 Jun 2009 13:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23158623.1244653316633.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer commented on JBAS-7008:
------------------------------------

Well the minimum would just be one ManagedObject for each entity bean with a 'name' property whose value is the EJB's name. As for metrics, I'm not sure what's available. If the Hibernate stats are not turned on, are there still any other metrics exposed by the EJB3 container for entity beans?


> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:18:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 13:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-128)
 DocumentBuilderFactory.setXIncludeAware set to true
Message-ID: <15329806.1244654336758.JavaMail.jira@cloud.prod.atl2.jboss.com>

DocumentBuilderFactory.setXIncludeAware set to true
---------------------------------------------------

                 Key: JBID-128
                 URL: https://jira.jboss.org/jira/browse/JBID-128
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


DocumentUtil needs to be updated to setXIncludeAware to true on the DocumentBuilderFactory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:18:58 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 13:18:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-128)
 DocumentBuilderFactory.setXIncludeAware set to true
In-Reply-To: <15329806.1244654336758.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12941644.1244654338565.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed JBID-128.
------------------------------

    Resolution: Done


> DocumentBuilderFactory.setXIncludeAware set to true
> ---------------------------------------------------
>
>                 Key: JBID-128
>                 URL: https://jira.jboss.org/jira/browse/JBID-128
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> DocumentUtil needs to be updated to setXIncludeAware to true on the DocumentBuilderFactory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:20:57 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 13:20:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-58) Improve
 SOAPSAMLXACMLServlet flexibility
In-Reply-To: <13222478.1235413244235.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2999218.1244654457271.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated JBID-58:
------------------------------

    Fix Version/s: IDFED-1.0.0.beta1
                       (was: IDFED-1.0.0.alpha3)


> Improve SOAPSAMLXACMLServlet flexibility
> ----------------------------------------
>
>                 Key: JBID-58
>                 URL: https://jira.jboss.org/jira/browse/JBID-58
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> This servlet can read SAML or XACML requests. It needs to be intelligent enough to figure out the response (whether saml or xacml) based on the type of request that was sent in.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:20:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 13:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-87) Developer FAQ on the
	wiki
In-Reply-To: <25054625.1240933666720.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31157158.1244654456644.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated JBID-87:
------------------------------

    Fix Version/s: IDFED-1.0.0.beta1
                       (was: IDFED-1.0.0.alpha3)


> Developer FAQ on the wiki
> -------------------------
>
>                 Key: JBID-87
>                 URL: https://jira.jboss.org/jira/browse/JBID-87
>             Project: JBoss Identity
>          Issue Type: Task
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> Need a developer FAQ to map requirements with the corresponding util/testcase.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:20:57 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 13:20:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-83) Implement token
 encryption (symmetric and public key)
In-Reply-To: <28214881.1240931398900.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4387629.1244654457125.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated JBID-83:
------------------------------

    Fix Version/s: IDFED-1.0.0.beta1
                       (was: IDFED-1.0.0.alpha3)


> Implement token encryption (symmetric and public key)
> -----------------------------------------------------
>
>                 Key: JBID-83
>                 URL: https://jira.jboss.org/jira/browse/JBID-83
>             Project: JBoss Identity
>          Issue Type: Task
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha2
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.beta1
>
>
> The request handler must encrypt the tokens generated by the security token provider when needed. We may use the XML Sec API to encrypt the returned tokens.
> Need to look for the XML Signature/Encryption utility for this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:20:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 13:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-85) Implement a script or
 tool to ease to creation of the STS war
In-Reply-To: <29985813.1240933186565.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22907183.1244654456919.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated JBID-85:
------------------------------

    Fix Version/s: IDFED-1.0.0.beta1
                       (was: IDFED-1.0.0.alpha3)


> Implement a script or tool to ease to creation of the STS war
> -------------------------------------------------------------
>
>                 Key: JBID-85
>                 URL: https://jira.jboss.org/jira/browse/JBID-85
>             Project: JBoss Identity
>          Issue Type: Task
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha2
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.beta1
>
>
> The JBossSTS is a web service provider that needs to be packaged as a war and include all relevant configuration files (such as web.xml, wsdl, jboss-sts.xml). We need to create a script to assist the user in the process of creating the config files and the STS war that will be deployed on JBoss.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:24:56 2009
From: jira-events at lists.jboss.org (Scott Clasen (JIRA))
Date: Wed, 10 Jun 2009 13:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
Message-ID: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>

unable to restart live/backup pair after clean stop
---------------------------------------------------

                 Key: JBMESSAGING-1646
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0 Beta
         Environment: Standalone JBM 2.0-BETA servers on 2 RHEL 64 bit. JDK 1.6.0_13
            Reporter: Scott Clasen
            Assignee: Tim Fox


Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.

Start Backup--->
 12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
 12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 

Start Live-->
 12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
 12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
 12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 

Backup sees live -->
 12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
 12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
 12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 

Live up->
 12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started

Stop live--->
[sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
[sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 

Stop Backup-->
[sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
[sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
java.lang.NullPointerException
	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
	at java.util.TimerThread.mainLoop(Timer.java:512)
	at java.util.TimerThread.run(Timer.java:462)

Restart Backup-->

15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 

Restart Live-->
12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 


Backup sees Live-->
12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)







-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:27:09 2009
From: jira-events at lists.jboss.org (Scott Clasen (JIRA))
Date: Wed, 10 Jun 2009 13:27:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13329878.1244654829116.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott Clasen updated JBMESSAGING-1646:
--------------------------------------

    Attachment: jbm-configuration.xml


This is the jbm-configuration.xml for the live server of the pair

> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta
>         Environment: Standalone JBM 2.0-BETA servers on 2 RHEL 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:27:09 2009
From: jira-events at lists.jboss.org (Scott Clasen (JIRA))
Date: Wed, 10 Jun 2009 13:27:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7402143.1244654829855.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott Clasen updated JBMESSAGING-1646:
--------------------------------------

    Attachment: jbm-configuration.xml


this is the jbm-configuration.xml for the backup

> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta
>         Environment: Standalone JBM 2.0-BETA servers on 2 RHEL 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:28:56 2009
From: jira-events at lists.jboss.org (Scott Clasen (JIRA))
Date: Wed, 10 Jun 2009 13:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5385717.1244654936505.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott Clasen updated JBMESSAGING-1646:
--------------------------------------

    Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13  (was: Standalone JBM 2.0-BETA servers on 2 RHEL 64 bit. JDK 1.6.0_13)


> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta
>         Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:38:07 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 10 Jun 2009 13:38:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29703161.1244655487624.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic updated JBMESSAGING-1646:
-----------------------------------------

    Fix Version/s: 2.0.0


> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta
>         Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:42:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 13:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-87) Developer FAQ on the
	wiki
In-Reply-To: <25054625.1240933666720.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6661036.1244655776475.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed JBID-87.
-----------------------------

    Resolution: Done


http://www.jboss.org/community/wiki/JBossIdentityFederation  has the Developer FAQ section.

> Developer FAQ on the wiki
> -------------------------
>
>                 Key: JBID-87
>                 URL: https://jira.jboss.org/jira/browse/JBID-87
>             Project: JBoss Identity
>          Issue Type: Task
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> Need a developer FAQ to map requirements with the corresponding util/testcase.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 14:22:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 10 Jun 2009 14:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-93) Define
 @ManagementProperty ServerConfig.getSpecificationVersion
In-Reply-To: <19526088.1244469536566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18412644.1244658176575.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger resolved JBBOOT-93.
---------------------------------------

    Resolution: Done


> Define @ManagementProperty ServerConfig.getSpecificationVersion
> ---------------------------------------------------------------
>
>                 Key: JBBOOT-93
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-93
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-as
>    Affects Versions: 2.0.0-alpha-1
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: impl-as-2.0.0-alpha-2
>
>
> This is required by Jopr.
> 09:32:48,964 WARN  [InventoryManager] Failure during discovery for [JBossAS Server] Resources - failed after 6282 ms.
> java.lang.Exception: Discovery component invocation failed.
>         at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:248)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:123)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.IllegalStateException: Property named 'specificationVersion' not found for ManagedComponent [org.jboss.managed.plugins.ManagedComponentImpl at 24b80637{name=jboss.system:type=ServerConfig, type=ComponentType{type=MCBean, subtype=ServerConfig}, owner=ManagedDeployment at 1381870081}].
>         at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSimplePropertyValue(ManagedComponentUtils.java:73)
>         at org.rhq.plugins.jbossas5.ApplicationServerDiscoveryComponent.discoverInProcessJBossAS(ApplicationServerDiscoveryComponent.java:281)
>         at org.rhq.plugins.jbossas5.ApplicationServerDiscoveryComponent.discoverResources(ApplicationServerDiscoveryComponent.java:102)
>         at sun.reflect.GeneratedMethodAccessor311.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
>         ... 5 more
> Legacy has:
> ctor:
> serverSpecificationVersion = thisPackage.getSpecificationVersion();
> @ManagementProperty(description="the server Specification-Version",
>          use={ViewUse.STATISTIC})
>    public String getSpecificationVersion()
>    {
>       return serverSpecificationVersion;
>    }
> Remove the STATISTIC use and mark read-only.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 14:22:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 10 Jun 2009 14:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7003) Jopr does not start
 in Branch_5_x
In-Reply-To: <8325659.1244469296878.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15273205.1244658176706.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger resolved JBAS-7003.
---------------------------------------

    Resolution: Done


> Jopr does not start in Branch_5_x
> ---------------------------------
>
>                 Key: JBAS-7003
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7003
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Container task to track any problems relating to Jopr not starting in AS Branch_5_x.
> Any runtime/deploytime failures need a corresponding testcase.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 14:24:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 10 Jun 2009 14:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Work started: (JBPORTAL-2409) Unable to
 delete property without value in portal admin interface
In-Reply-To: <15281741.1244549276551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8148994.1244658296705.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Work on JBPORTAL-2409 started by Chris Laprun.

> Unable to delete property without value in portal admin interface
> -----------------------------------------------------------------
>
>                 Key: JBPORTAL-2409
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2409
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Web
>    Affects Versions: 2.7.3 Final
>            Reporter: Viliam Rockai
>            Assignee: Chris Laprun
>
> This bug is present in at least three places:
> -Manage properties for all portals
> -Properties of each portal
> -Dashboards  
> in these interfaces it is possible to add values with custom names. when the property is added, it's default value is blank. when a property with blank value is to be deleted (clicking on the delete icon next to the property) nothing will happen. if some value is added to the property, it can be deleted. If you delete the value of some existing property, it can't be deleted.
> after clicking on delete button (page is reloaded) for property without a value, you cannot even delete properties with values until you set values to the blank fields.
> excerpt from the log:
> 14:07:45,694 ERROR [STDERR] Jun 9, 2009 2:07:45 PM javax.faces.component.UIInput updateModel
> SEVERE: /jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean
> java.lang.NullPointerException
> 	at org.jboss.portal.faces.gui.ManagedBean.getLocalizedType(ManagedBean.java:131)
> 	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:85)
> 	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:75)
> 	at org.jboss.portal.core.admin.ui.PropertyBean.setValue(PropertyBean.java:108)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> .........
> 14:07:45,918 INFO  [lifecycle] WARNING: FacesMessage(s) have been enqueued, but may not have been displayed.
> sourceId=_AdminPortletWindow:j_id132:common-manage-prop-form:prop-data-table:0:prop-value-input[severity=(ERROR 2), summary=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean), detail=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean)]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 14:41:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 10 Jun 2009 14:41:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-6982) unable to connect
 to Profile Service remotely using EJB remote interface
In-Reply-To: <33034814.1243442816774.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24494373.1244659317095.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer reopened JBAS-6982:
--------------------------------



I'm still getting a "javax.ejb.EJBAccessException: Caller unauthorized" using either set of credentials.

It looks like the difference may be in the method I'm using to authenticate. I'm setting the principal and credentials in the env props I pass when creating the InitialContext. My client code is at:

  https://svn.jboss.org/repos/jopr/trunk/etc/jbas5-ejb-client/src/main/java/test/EjbClient.java

Whereas in:

   https://svn.jboss.org/repos/jbossas/branches/JBPAPP_5_0/testsuite/src/main/org/jboss/test/profileservice/testsecure/ProfileServiceUnitTestCase.java

you are instead directly using JAAS to authenticate prior to doing the JNDI lookups. Is the method I'm using supposed to work or do I need to switch to the JAAS method?


> unable to connect to Profile Service remotely using EJB remote interface
> ------------------------------------------------------------------------
>
>                 Key: JBAS-6982
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6982
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The non-EJB remote interface is working, with the exception of the various class loading exceptions. The EJB interface is not, due to an authentication failure, but I think it used to work.
> Here's the log output showing me doing the JNDI lookup of the EJB proxies:
> DEBUG 27-05 12:40:03,988 (RemoteProfileServiceConnectionProvider.java:doConnect:90)  -Connecting to Profile Service via remote JNDI using env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:03,988 (AbstractProfileServiceConnectionProvider.java:createInitialContext:74)  -Creating JNDI InitialContext with env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:04,004 (Logger.java:debug:228)  -Using ThreadLocal: false
> DEBUG 27-05 12:40:04,035 (AbstractProfileServiceConnectionProvider.java:createInitialContext:83)  -Created JNDI InitialContext [javax.naming.InitialContext at 1ccb029].
> DEBUG 27-05 12:40:04,035 (Logger.java:debug:228)  -createSocket, hostAddr: /127.0.0.1, port: 1099, localAddr: null, localPort: 0, timeout: 0
> DEBUG 27-05 12:40:04,191 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureProfileService/remote
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Encrypted Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -removed SocketClientInvoker[3820e, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -Created Proxy of type $Proxy1 for EJB3 Business Interface: org.jboss.profileservice.spi.ProfileService
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureManagementView/remote
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -removed SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Created Proxy of type $Proxy3 for EJB3 Business Interface: org.jboss.deployers.spi.management.ManagementView
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureDeploymentManager/remote
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -removed SocketClientInvoker[12940b3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Created Proxy of type $Proxy5 for EJB3 Business Interface: org.jboss.deployers.spi.management.deploy.DeploymentManager
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Couldn't handle invocation directly within org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8: Current invocation "public abstract boolean org.jboss.deployers.spi.management.ManagementView.load()" is not eligible for direct handling by org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Received invocation request to method org.jboss.deployers.spi.management.ManagementView: org.jboss.deployers.spi.management.ManagementView.load(); using hash: -657996635075089079
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -removed SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] disconnecting ...
> And here's the "EJBAccessException: Caller unauthorized" that occurs when I call load() on the ManagementView proxy:
> Exception in thread "main" javax.ejb.EJBAccessException: Caller unauthorized
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:199)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         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:524)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 14:47:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 10 Jun 2009 14:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27099900.1244659676718.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox commented on JBMESSAGING-1646:
--------------------------------------

Thanks Scott-

I'll take a proper look tomorrow, but I think I know what the problem might be. Should be able to get this fixed tomorrow.

> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta
>         Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 15:44:57 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 10 Jun 2009 15:44:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-96) SJC Resource Adapter
	deployer
Message-ID: <17573123.1244663097253.JavaMail.jira@cloud.prod.atl2.jboss.com>

SJC Resource Adapter deployer
-----------------------------

                 Key: JBJCA-96
                 URL: https://jira.jboss.org/jira/browse/JBJCA-96
             Project: JBoss JCA
          Issue Type: Task
          Components: Core
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha1


Create a resource adapter deployer for SJC

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 16:01:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 16:01:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6982) unable to connect
 to Profile Service remotely using EJB remote interface
In-Reply-To: <33034814.1243442816774.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31535993.1244664117256.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark commented on JBAS-6982:
-------------------------------------

Both approaches should work, so I added a test using the InitialContextFactory and I do see the error you do. I'm looking into that.

> unable to connect to Profile Service remotely using EJB remote interface
> ------------------------------------------------------------------------
>
>                 Key: JBAS-6982
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6982
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The non-EJB remote interface is working, with the exception of the various class loading exceptions. The EJB interface is not, due to an authentication failure, but I think it used to work.
> Here's the log output showing me doing the JNDI lookup of the EJB proxies:
> DEBUG 27-05 12:40:03,988 (RemoteProfileServiceConnectionProvider.java:doConnect:90)  -Connecting to Profile Service via remote JNDI using env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:03,988 (AbstractProfileServiceConnectionProvider.java:createInitialContext:74)  -Creating JNDI InitialContext with env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:04,004 (Logger.java:debug:228)  -Using ThreadLocal: false
> DEBUG 27-05 12:40:04,035 (AbstractProfileServiceConnectionProvider.java:createInitialContext:83)  -Created JNDI InitialContext [javax.naming.InitialContext at 1ccb029].
> DEBUG 27-05 12:40:04,035 (Logger.java:debug:228)  -createSocket, hostAddr: /127.0.0.1, port: 1099, localAddr: null, localPort: 0, timeout: 0
> DEBUG 27-05 12:40:04,191 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureProfileService/remote
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Encrypted Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -removed SocketClientInvoker[3820e, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -Created Proxy of type $Proxy1 for EJB3 Business Interface: org.jboss.profileservice.spi.ProfileService
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureManagementView/remote
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -removed SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Created Proxy of type $Proxy3 for EJB3 Business Interface: org.jboss.deployers.spi.management.ManagementView
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureDeploymentManager/remote
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -removed SocketClientInvoker[12940b3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Created Proxy of type $Proxy5 for EJB3 Business Interface: org.jboss.deployers.spi.management.deploy.DeploymentManager
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Couldn't handle invocation directly within org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8: Current invocation "public abstract boolean org.jboss.deployers.spi.management.ManagementView.load()" is not eligible for direct handling by org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Received invocation request to method org.jboss.deployers.spi.management.ManagementView: org.jboss.deployers.spi.management.ManagementView.load(); using hash: -657996635075089079
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -removed SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] disconnecting ...
> And here's the "EJBAccessException: Caller unauthorized" that occurs when I call load() on the ManagementView proxy:
> Exception in thread "main" javax.ejb.EJBAccessException: Caller unauthorized
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:199)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         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:524)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 16:21:56 2009
From: jira-events at lists.jboss.org (Scott Clasen (JIRA))
Date: Wed, 10 Jun 2009 16:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1647) Correct
 system property
 name in JBMBootstrapServer, add setting of property to start script, add
 config dir to stop script.
Message-ID: <29497109.1244665316669.JavaMail.jira@cloud.prod.atl2.jboss.com>

Correct system property name in JBMBootstrapServer, add setting of property to start script, add config dir to stop script.
---------------------------------------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1647
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1647
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0 Beta
            Reporter: Scott Clasen
            Assignee: Tim Fox


Line 88 of JBMBootstrapServer  is

String dirName = System.getProperty("jbm.bootsrap.bin.dir", ".");

Property should be jbm.bootstrap.bin.dir instead of jbm.bootsrap.bin.dir?

Also the start and stop scripts in the bin dir should probably work by setting this property based on the config dir you use, so KILL_ME gets touched in the config dir

So run.sh should set -Djbm.bootstrap.bin.dir=$CONFIG_DIR

and stop.sh should capture $1 as $CONFIG_DIR and  touch $CONFIG_DIR/KILL_ME

otherwise if you are running 2 configs out of the same distro...like

/messaging-2.0.0.BETA1/bin/run.sh /path/to/config/one &
/messaging-2.0.0.BETA1/bin/run.sh /path/to/config/two &

CURRENT 
/messaging-2.0.0.BETA1/bin/stop.sh  
 //-->BRINGS DOWN BOTH SERVERS

CHANGED
/messaging-2.0.0.BETA1/bin/stop.sh /path/to/config/one 
//-->Brings down only server one








-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 16:38:57 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 10 Jun 2009 16:38:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7009) AS JChannelFactory
 shouldn't subclass the JGroups version
Message-ID: <14168838.1244666337520.JavaMail.jira@cloud.prod.atl2.jboss.com>

AS JChannelFactory shouldn't subclass the JGroups version
---------------------------------------------------------

                 Key: JBAS-7009
                 URL: https://jira.jboss.org/jira/browse/JBAS-7009
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-6.0.0.Alpha1


The AS JChannelFactory class started off as a subclass of the JGroups version with a few small differences. Over time it has added a lot of specialized behavior, and exposing a full-featured ManagedObject interface requires adding significantly more. At this point the benefits of subclassing don't justify the hassle of keeping them coupled.

Both implement the ChannelFactory interface, which is the client view.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 16:42:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 10 Jun 2009 16:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-988) Add API to manipulate
 JChannelFactory stacks member
In-Reply-To: <22228859.1244566736540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1234398.1244666576517.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry closed JGRP-988.
---------------------------------

    Fix Version/s:     (was: 2.6.11)
       Resolution: Won't Fix


Never mind; it's better for the AS to stop subclassing; that works fine: JBAS-7009

> Add API to manipulate JChannelFactory stacks member
> ---------------------------------------------------
>
>                 Key: JGRP-988
>                 URL: https://jira.jboss.org/jira/browse/JGRP-988
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> I'd like to see the following methods added to JChannelFactory to go along with the existing getConfig and removeConfig.  These will allow the JBoss AS-specific subclass to update the contents of the "stacks" member in response to updates from management tools like the embedded console or Jopr:
> public boolean addConfig(String stack_name, String config, boolean replace) {
>    boolean added = replace;
>    if(replace) {
>        stacks.put(st_name, val);
>        if(log.isTraceEnabled())
>            log.trace("added config '" + st_name + "'");
>     }
>     else {
>         if(!stacks.containsKey(st_name)) {
>             stacks.put(st_name, val);
>             added = true;
>             if(log.isTraceEnabled())
>                log.trace("added config '" + st_name + "'");
>     }
>     else {
>          if(log.isTraceEnabled())
>            log.trace("didn't add config '" + st_name + " because one of the same name already existed");
>     }
>     return added;
> }
> public Set<String> getConfigNames() {
>    return Collections.unmodifiableSet(stacks.keySet());
> }
> Bela, I've assigned this to you to get your feedback on it, but I'd be happy to do it. Just assign back to me.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 18:22:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 10 Jun 2009 18:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-2409) Unable to
 delete property without value in portal admin interface
In-Reply-To: <15281741.1244549276551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25994567.1244672576799.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Chris Laprun resolved JBPORTAL-2409.
------------------------------------

    Resolution: Done


> Unable to delete property without value in portal admin interface
> -----------------------------------------------------------------
>
>                 Key: JBPORTAL-2409
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2409
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.7.2 Final
>            Reporter: Viliam Rockai
>            Assignee: Chris Laprun
>             Fix For: 2.7.3 Final
>
>
> This bug is present in at least three places:
> -Manage properties for all portals
> -Properties of each portal
> -Dashboards  
> in these interfaces it is possible to add values with custom names. when the property is added, it's default value is blank. when a property with blank value is to be deleted (clicking on the delete icon next to the property) nothing will happen. if some value is added to the property, it can be deleted. If you delete the value of some existing property, it can't be deleted.
> after clicking on delete button (page is reloaded) for property without a value, you cannot even delete properties with values until you set values to the blank fields.
> excerpt from the log:
> 14:07:45,694 ERROR [STDERR] Jun 9, 2009 2:07:45 PM javax.faces.component.UIInput updateModel
> SEVERE: /jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean
> java.lang.NullPointerException
> 	at org.jboss.portal.faces.gui.ManagedBean.getLocalizedType(ManagedBean.java:131)
> 	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:85)
> 	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:75)
> 	at org.jboss.portal.core.admin.ui.PropertyBean.setValue(PropertyBean.java:108)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> .........
> 14:07:45,918 INFO  [lifecycle] WARNING: FacesMessage(s) have been enqueued, but may not have been displayed.
> sourceId=_AdminPortletWindow:j_id132:common-manage-prop-form:prop-data-table:0:prop-value-input[severity=(ERROR 2), summary=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean), detail=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean)]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 18:22:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 10 Jun 2009 18:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2409) Unable to delete
 property without value in portal admin interface
In-Reply-To: <15281741.1244549276551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3153980.1244672576621.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Chris Laprun updated JBPORTAL-2409:
-----------------------------------

          Component/s: Portal Core Admin
                           (was: Portal Web)
        Fix Version/s: 2.7.3 Final
    Affects Version/s: 2.7.2 Final
                           (was: 2.7.3 Final)


> Unable to delete property without value in portal admin interface
> -----------------------------------------------------------------
>
>                 Key: JBPORTAL-2409
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2409
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.7.2 Final
>            Reporter: Viliam Rockai
>            Assignee: Chris Laprun
>             Fix For: 2.7.3 Final
>
>
> This bug is present in at least three places:
> -Manage properties for all portals
> -Properties of each portal
> -Dashboards  
> in these interfaces it is possible to add values with custom names. when the property is added, it's default value is blank. when a property with blank value is to be deleted (clicking on the delete icon next to the property) nothing will happen. if some value is added to the property, it can be deleted. If you delete the value of some existing property, it can't be deleted.
> after clicking on delete button (page is reloaded) for property without a value, you cannot even delete properties with values until you set values to the blank fields.
> excerpt from the log:
> 14:07:45,694 ERROR [STDERR] Jun 9, 2009 2:07:45 PM javax.faces.component.UIInput updateModel
> SEVERE: /jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean
> java.lang.NullPointerException
> 	at org.jboss.portal.faces.gui.ManagedBean.getLocalizedType(ManagedBean.java:131)
> 	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:85)
> 	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:75)
> 	at org.jboss.portal.core.admin.ui.PropertyBean.setValue(PropertyBean.java:108)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> .........
> 14:07:45,918 INFO  [lifecycle] WARNING: FacesMessage(s) have been enqueued, but may not have been displayed.
> sourceId=_AdminPortletWindow:j_id132:common-manage-prop-form:prop-data-table:0:prop-value-input[severity=(ERROR 2), summary=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean), detail=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean)]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 19:30:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 19:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7010)
 JndiLoginInitialContextFactory is
 not creating expected SecurityContext
Message-ID: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>

JndiLoginInitialContextFactory is not creating expected SecurityContext
-----------------------------------------------------------------------

                 Key: JBAS-7010
                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Naming, Security
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Scott M Stark
            Assignee: Scott M Stark


Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 19:34:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 19:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22946726.1244676896447.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-7010.
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Resolution: Done


I updated the JndiLoginInitialContextFactory security actions to be consistent with the ClientLoginModule

> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 19:36:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 19:36:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6982) unable to connect
 to Profile Service remotely using EJB remote interface
In-Reply-To: <33034814.1243442816774.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10889083.1244677017256.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-6982.
---------------------------------

    Resolution: Done


The issue was JBAS-7010, which I have fixed and the test using the JndiLoginInitialContextFactory is now passing

> unable to connect to Profile Service remotely using EJB remote interface
> ------------------------------------------------------------------------
>
>                 Key: JBAS-6982
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6982
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The non-EJB remote interface is working, with the exception of the various class loading exceptions. The EJB interface is not, due to an authentication failure, but I think it used to work.
> Here's the log output showing me doing the JNDI lookup of the EJB proxies:
> DEBUG 27-05 12:40:03,988 (RemoteProfileServiceConnectionProvider.java:doConnect:90)  -Connecting to Profile Service via remote JNDI using env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:03,988 (AbstractProfileServiceConnectionProvider.java:createInitialContext:74)  -Creating JNDI InitialContext with env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:04,004 (Logger.java:debug:228)  -Using ThreadLocal: false
> DEBUG 27-05 12:40:04,035 (AbstractProfileServiceConnectionProvider.java:createInitialContext:83)  -Created JNDI InitialContext [javax.naming.InitialContext at 1ccb029].
> DEBUG 27-05 12:40:04,035 (Logger.java:debug:228)  -createSocket, hostAddr: /127.0.0.1, port: 1099, localAddr: null, localPort: 0, timeout: 0
> DEBUG 27-05 12:40:04,191 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureProfileService/remote
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Encrypted Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -removed SocketClientInvoker[3820e, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -Created Proxy of type $Proxy1 for EJB3 Business Interface: org.jboss.profileservice.spi.ProfileService
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureManagementView/remote
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -removed SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Created Proxy of type $Proxy3 for EJB3 Business Interface: org.jboss.deployers.spi.management.ManagementView
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureDeploymentManager/remote
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -removed SocketClientInvoker[12940b3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Created Proxy of type $Proxy5 for EJB3 Business Interface: org.jboss.deployers.spi.management.deploy.DeploymentManager
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Couldn't handle invocation directly within org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8: Current invocation "public abstract boolean org.jboss.deployers.spi.management.ManagementView.load()" is not eligible for direct handling by org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Received invocation request to method org.jboss.deployers.spi.management.ManagementView: org.jboss.deployers.spi.management.ManagementView.load(); using hash: -657996635075089079
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -removed SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] disconnecting ...
> And here's the "EJBAccessException: Caller unauthorized" that occurs when I call load() on the ManagementView proxy:
> Exception in thread "main" javax.ejb.EJBAccessException: Caller unauthorized
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:199)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         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:524)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 20:00:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Wed, 10 Jun 2009 20:00:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREFLECT-53) Replace Arrays
 with varargs on all getDeclaredXXXMethods
Message-ID: <27973728.1244678456555.JavaMail.jira@cloud.prod.atl2.jboss.com>

Replace Arrays with varargs on all getDeclaredXXXMethods
--------------------------------------------------------

                 Key: JBREFLECT-53
                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-53
             Project: JBoss Reflection
          Issue Type: Task
          Components: ClassInfo
    Affects Versions: JBossReflection.2.0.2.GA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: JBossReflection.2.2.0-Beta1 


Similar to what was done on java.lang.Class<?>.getDeclaredMethods(....) and java.lang.Class<?>.getDeclaredConstructors(), we should replace type parameter arrays with varargs on everywhere that is appliable.

This maintains the backwards compatibility with old version, as callers can still use the array, but adds simplicity for new users, that get rid of having to create a type array everytime they need to invoke those methods.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 21:51:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 10 Jun 2009 21:51:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2117) fireAllRules()
 blocks if called while fireUntilHalt() is running
Message-ID: <18433550.1244685116605.JavaMail.jira@cloud.prod.atl2.jboss.com>

fireAllRules() blocks if called while fireUntilHalt() is running
----------------------------------------------------------------

                 Key: JBRULES-2117
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2117
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


Drools work items call fireAllRules() automatically after completion. If the engine is already running fireUntilHalt() though, it blocks.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 22:17:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 10 Jun 2009 22:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
Message-ID: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>

Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
--------------------------------------------------------------

                 Key: JBWEB-142
                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
             Project: JBoss Web
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Tomcat
    Affects Versions: JBossWeb-2.0.0.GA_CP10
            Reporter: Mike Millson
            Assignee: Remy Maucherat


Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).

Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.

Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 22:34:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 10 Jun 2009 22:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2117) fireAllRules()
 blocks if called while fireUntilHalt() is running
In-Reply-To: <18433550.1244685116605.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6071314.1244687696548.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli closed JBRULES-2117.
----------------------------------

    Resolution: Done


Fixed.

> fireAllRules() blocks if called while fireUntilHalt() is running
> ----------------------------------------------------------------
>
>                 Key: JBRULES-2117
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2117
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> Drools work items call fireAllRules() automatically after completion. If the engine is already running fireUntilHalt() though, it blocks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 22:37:07 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 10 Jun 2009 22:37:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2117) fireAllRules()
 blocks if called while fireUntilHalt() is running
In-Reply-To: <18433550.1244685116605.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9651522.1244687827663.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli closed JBRULES-2117.
----------------------------------

    Fix Version/s: 5.0.2
       Resolution: Done


> fireAllRules() blocks if called while fireUntilHalt() is running
> ----------------------------------------------------------------
>
>                 Key: JBRULES-2117
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2117
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.0.2, 5.1.0.M1
>
>
> Drools work items call fireAllRules() automatically after completion. If the engine is already running fireUntilHalt() though, it blocks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 22:37:07 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 10 Jun 2009 22:37:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-2117) fireAllRules()
 blocks if called while fireUntilHalt() is running
In-Reply-To: <18433550.1244685116605.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22107332.1244687827536.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli reopened JBRULES-2117:
------------------------------------



> fireAllRules() blocks if called while fireUntilHalt() is running
> ----------------------------------------------------------------
>
>                 Key: JBRULES-2117
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2117
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.0.2, 5.1.0.M1
>
>
> Drools work items call fireAllRules() automatically after completion. If the engine is already running fireUntilHalt() though, it blocks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 23:17:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 10 Jun 2009 23:17:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1641) Stopping the
 bridge service doesn't stop the failure handler
In-Reply-To: <31429260.1244473017316.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28752914.1244690277204.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao closed JBMESSAGING-1641.
-----------------------------------

    Resolution: Done


done. Manually tested from JMX console.

> Stopping the bridge service doesn't stop the failure handler
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1641
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1641
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> when bridge is stopped via the JMX, the stop() action doesn't stop the failure handler, which will keep trying to reconnect even after bridge service has been stopped.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 01:59:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 11 Jun 2009 01:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBREFLECT-3) Use the
 ScopedClassPool from javassist
In-Reply-To: <12331947.1165415635891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17279629.1244699996729.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin reassigned JBREFLECT-3:
-----------------------------------

    Assignee: Flavia Rainone  (was: Ales Justin)


> Use the ScopedClassPool from javassist
> --------------------------------------
>
>                 Key: JBREFLECT-3
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-3
>             Project: JBoss Reflection
>          Issue Type: Task
>          Components: Javassist
>            Reporter: Adrian Brock
>            Assignee: Flavia Rainone
>
> The javassist reflection utilities use the original shared classpool.
> This does not understand classloaders.
> This should be updated to use the newer ScopedClassPool from javassist.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 01:59:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 11 Jun 2009 01:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBREFLECT-6) Javassist based
 reflection objects uses the compiler
In-Reply-To: <5081114.1165415515640.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24519883.1244699997005.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin reassigned JBREFLECT-6:
-----------------------------------

    Assignee: Flavia Rainone  (was: Ales Justin)


> Javassist based reflection objects uses the compiler
> ----------------------------------------------------
>
>                 Key: JBREFLECT-6
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-6
>             Project: JBoss Reflection
>          Issue Type: Task
>          Components: Javassist
>            Reporter: Adrian Brock
>            Assignee: Flavia Rainone
>
> The JavassistReflectionFactory builds up a source to compile the method, constructor and field accesors.
> These implementations are faster than the normal reflection equivalents, but using the compiler is slow.
> These methods should be optimized to generate the bytecode directly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 02:03:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 11 Jun 2009 02:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <15323501.1244700236973.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1631:
-----------------------------------------

Hi Victor,

Just an update. My test has been running over night without message pile up at either node. I found the client failover didn't happen as my two machines are in a local network. 

I'll further reduce the ping timeout (already 500ms). However, as the MDB is deployed within the App Server. If the MDB is connected to the same Server, it's unlikely that client failover will happen.
One possible reason that may affect the message sucker is that if the message sucker's connection has ping timeout. I'll try to make this happen to see if I can made any progress.

Alse please note you should use remoting 2.2.3. remoting 2.5.1 doesn't include all the fixes for JBMESSAGING-1456.

> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 02:06:07 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 11 Jun 2009 02:06:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1847) Fix logging of
 irrelevant (for end users) message about WebService context property
Message-ID: <20139007.1244700367599.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix logging of irrelevant (for end users) message about WebService context property  
-------------------------------------------------------------------------------------

                 Key: EJBTHREE-1847
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1847
             Project: EJB 3.0
          Issue Type: Task
          Components: core
    Affects Versions: 1.1.6
            Reporter: jaikiran pai
            Assignee: jaikiran pai


We currently log this message 

[StatelessBeanContext]  EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected

which is of no relevance to the end user. We need to fix this. Please see referenced forum thread for details.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 02:37:56 2009
From: jira-events at lists.jboss.org (Penkov Vladimir (JIRA))
Date: Thu, 11 Jun 2009 02:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2421) tomahawk
 doesn't see users's roles
In-Reply-To: <31888261.1244644076879.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9500023.1244702276768.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471634#action_12471634 ] 

Penkov Vladimir commented on JBPORTAL-2421:
-------------------------------------------

One must add

        <security-role-ref>
            <role-name>User</role-name>
        </security-role-ref>

to portlet.xml

> tomahawk doesn't see users's roles
> ----------------------------------
>
>                 Key: JBPORTAL-2421
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2421
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Security
>    Affects Versions: 2.7.2 Final
>            Reporter: Penkov Vladimir
>
> Create user, give him 'User' role. 
> Create jsf portlet with jsfbridge. Add to some page:
> <t:commandLink ... enabledOnUserRole="User">
> Authenticate as created user. Visit this page. Link will always be disabled.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 03:29:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 11 Jun 2009 03:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1647) Correct
 system property
 name in JBMBootstrapServer, add setting of property to start script, add
 config dir to stop script.
In-Reply-To: <29497109.1244665316669.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28815159.1244705396671.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1647:
---------------------------------

    Fix Version/s: 2.0.0
         Assignee: Andy Taylor  (was: Tim Fox)


> Correct system property name in JBMBootstrapServer, add setting of property to start script, add config dir to stop script.
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1647
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1647
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta
>            Reporter: Scott Clasen
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>
> Line 88 of JBMBootstrapServer  is
> String dirName = System.getProperty("jbm.bootsrap.bin.dir", ".");
> Property should be jbm.bootstrap.bin.dir instead of jbm.bootsrap.bin.dir?
> Also the start and stop scripts in the bin dir should probably work by setting this property based on the config dir you use, so KILL_ME gets touched in the config dir
> So run.sh should set -Djbm.bootstrap.bin.dir=$CONFIG_DIR
> and stop.sh should capture $1 as $CONFIG_DIR and  touch $CONFIG_DIR/KILL_ME
> otherwise if you are running 2 configs out of the same distro...like
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/one &
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/two &
> CURRENT 
> /messaging-2.0.0.BETA1/bin/stop.sh  
>  //-->BRINGS DOWN BOTH SERVERS
> CHANGED
> /messaging-2.0.0.BETA1/bin/stop.sh /path/to/config/one 
> //-->Brings down only server one

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 04:10:59 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 11 Jun 2009 04:10:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-207) Default
 SchemaBindingResolver impl may loose location/uri to class mapping
Message-ID: <28200716.1244707859087.JavaMail.jira@cloud.prod.atl2.jboss.com>

Default SchemaBindingResolver impl may loose location/uri to class mapping
--------------------------------------------------------------------------

                 Key: JBXB-207
                 URL: https://jira.jboss.org/jira/browse/JBXB-207
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.1.GA
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossXB-2.0.2.GA


MultiClassSchemaResolver and DefaultSchemaResolver use WeakHashMap for uriToClass and schemaLocationToClass maps. Both of them are supposed to contain mappings set by a user using public methods mapLocationToClass(String schemaLocation, Class<?> clazz), mapURIToClass(String nsUri, Class<?> clazz), etc. None of the maps is used as an internal cache during schema binding resolution, i.e. if a schema binding is resolved w/o a user-provided mapping the mapping could be added/cached into those maps (successfully resolved schemas are cached by their ns URI instead).
So, the fact that a user-provided mapping can disappear is confusing and wrong.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 06:34:57 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Thu, 11 Jun 2009 06:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1647) Correct system
 property
 name in JBMBootstrapServer, add setting of property to start script, add
 config dir to stop script.
In-Reply-To: <29497109.1244665316669.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1353769.1244716497193.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andy Taylor closed JBMESSAGING-1647.
------------------------------------

    Resolution: Done


fixed. Ive renamed the kill_me file to STOP_ME and it is now put under the config directory

> Correct system property name in JBMBootstrapServer, add setting of property to start script, add config dir to stop script.
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1647
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1647
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta
>            Reporter: Scott Clasen
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>
> Line 88 of JBMBootstrapServer  is
> String dirName = System.getProperty("jbm.bootsrap.bin.dir", ".");
> Property should be jbm.bootstrap.bin.dir instead of jbm.bootsrap.bin.dir?
> Also the start and stop scripts in the bin dir should probably work by setting this property based on the config dir you use, so KILL_ME gets touched in the config dir
> So run.sh should set -Djbm.bootstrap.bin.dir=$CONFIG_DIR
> and stop.sh should capture $1 as $CONFIG_DIR and  touch $CONFIG_DIR/KILL_ME
> otherwise if you are running 2 configs out of the same distro...like
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/one &
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/two &
> CURRENT 
> /messaging-2.0.0.BETA1/bin/stop.sh  
>  //-->BRINGS DOWN BOTH SERVERS
> CHANGED
> /messaging-2.0.0.BETA1/bin/stop.sh /path/to/config/one 
> //-->Brings down only server one

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 06:34:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 11 Jun 2009 06:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1648) Bridge may
 stop working after long time idle
Message-ID: <30049000.1244716497603.JavaMail.jira@cloud.prod.atl2.jboss.com>

Bridge may stop working after long time idle
--------------------------------------------

                 Key: JBMESSAGING-1648
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1648
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Facade
    Affects Versions: 1.4.3.GA
            Reporter: Howard Gao
            Assignee: Howard Gao
             Fix For: 1.4.5.GA


Bridge service may stop working after a long time idle

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 06:56:56 2009
From: jira-events at lists.jboss.org (Joao Paulo Viragine (JIRA))
Date: Thu, 11 Jun 2009 06:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2422) Change the name
 of casServerName parameter to casClientServerName/casClientName in
 CASAuthenticationValve
Message-ID: <16318858.1244717816473.JavaMail.jira@cloud.prod.atl2.jboss.com>

Change the name of casServerName parameter to casClientServerName/casClientName in CASAuthenticationValve
---------------------------------------------------------------------------------------------------------

                 Key: JBPORTAL-2422
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2422
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.7.2 Final
            Reporter: Joao Paulo Viragine




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 07:18:56 2009
From: jira-events at lists.jboss.org (Joao Paulo Viragine (JIRA))
Date: Thu, 11 Jun 2009 07:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2422) Change the name
 of casServerName parameter to casClientServerName/casClientName in
 CASAuthenticationValve
In-Reply-To: <16318858.1244717816473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30816297.1244719136685.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Joao Paulo Viragine updated JBPORTAL-2422:
------------------------------------------

    Description: 
Maybe separate the declaration of server and port.

Something like: casClientServerName and casClientPortNumber

Or as suggested by Posolda: casClientName. (for client server name and port)


> Change the name of casServerName parameter to casClientServerName/casClientName in CASAuthenticationValve
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2422
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2422
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.7.2 Final
>            Reporter: Joao Paulo Viragine
>
> Maybe separate the declaration of server and port.
> Something like: casClientServerName and casClientPortNumber
> Or as suggested by Posolda: casClientName. (for client server name and port)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 07:48:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 11 Jun 2009 07:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1847) Fix the issue
 that causes
 StatelessBeanContext to log a WARN message about WebServiceContext property
In-Reply-To: <20139007.1244700367599.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7575972.1244720936697.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai updated EJBTHREE-1847:
-----------------------------------

        Summary: Fix the issue that causes StatelessBeanContext to log a WARN message about WebServiceContext property  (was: Fix logging of irrelevant (for end users) message about WebService context property  )
    Description: 
We currently log this message 

[StatelessBeanContext]  EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected

which is of no relevance to the end user. We need to fix the the real issue which causes this log. Please see the referenced forum thread for details.


  was:
We currently log this message 

[StatelessBeanContext]  EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected

which is of no relevance to the end user. We need to fix this. Please see referenced forum thread for details.




> Fix the issue that causes StatelessBeanContext to log a WARN message about WebServiceContext property
> -----------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1847
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1847
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core
>    Affects Versions: 1.1.6
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> We currently log this message 
> [StatelessBeanContext]  EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected
> which is of no relevance to the end user. We need to fix the the real issue which causes this log. Please see the referenced forum thread for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 07:52:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 11 Jun 2009 07:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-989) TCPPING: add new
 member addresses to initial_hosts dynamically
Message-ID: <31320194.1244721176847.JavaMail.jira@cloud.prod.atl2.jboss.com>

TCPPING: add new member addresses to initial_hosts dynamically
--------------------------------------------------------------

                 Key: JGRP-989
                 URL: https://jira.jboss.org/jira/browse/JGRP-989
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


When we have A,B and C listed in initial_hosts but later D and E join, and we have a partition {A,B,C} and {D,E}, when the partition heals later, we have no way of merging the 2 subgroups back into 1 because initial_hosts doesn't contain D or E.
SOLUTION: dynamically add members not in initial_hosts to initial_hosts on view changes. Keep the number of dynamically added members bounded.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 07:59:12 2009
From: jira-events at lists.jboss.org (Vijayanandraj Amaladoss (JIRA))
Date: Thu, 11 Jun 2009 07:59:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBWEB-143) ThreadName in
	AccessLogValve
Message-ID: <5445829.1244721552450.JavaMail.jira@cloud.prod.atl2.jboss.com>

 ThreadName in AccessLogValve
-----------------------------

                 Key: JBWEB-143
                 URL: https://jira.jboss.org/jira/browse/JBWEB-143
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Core
    Affects Versions: JBossWeb-2.0.0.GA
         Environment: Jboss 4.2 GA EAP / Any operating system
            Reporter: Vijayanandraj Amaladoss
            Assignee: Remy Maucherat


Writing the thread name in the access log using "%I" pattern is not supported in Jboss web 2.0 GA. This is implemented in Jboss web 2.1.2 GA.

Please refer to thread

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236960'




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 08:02:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 11 Jun 2009 08:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-207) Default
 SchemaBindingResolver impl may loose location/uri to class mapping
In-Reply-To: <28200716.1244707859087.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11009975.1244721776464.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Alexey Loubyansky closed JBXB-207.
----------------------------------

    Resolution: Done


Done.

> Default SchemaBindingResolver impl may loose location/uri to class mapping
> --------------------------------------------------------------------------
>
>                 Key: JBXB-207
>                 URL: https://jira.jboss.org/jira/browse/JBXB-207
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> MultiClassSchemaResolver and DefaultSchemaResolver use WeakHashMap for uriToClass and schemaLocationToClass maps. Both of them are supposed to contain mappings set by a user using public methods mapLocationToClass(String schemaLocation, Class<?> clazz), mapURIToClass(String nsUri, Class<?> clazz), etc. None of the maps is used as an internal cache during schema binding resolution, i.e. if a schema binding is resolved w/o a user-provided mapping the mapping could be added/cached into those maps (successfully resolved schemas are cached by their ns URI instead).
> So, the fact that a user-provided mapping can disappear is confusing and wrong.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 08:52:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 11 Jun 2009 08:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-88) ViewUse getting lost
 during serialization
Message-ID: <21552121.1244724776829.JavaMail.jira@cloud.prod.atl2.jboss.com>

ViewUse getting lost during serialization
-----------------------------------------

                 Key: JBMAN-88
                 URL: https://jira.jboss.org/jira/browse/JBMAN-88
             Project: JBoss Managed
          Issue Type: Bug
    Affects Versions: JBossMan.2.1.1.Beta3
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber


Since the annotations are transient, the ViewUse cannot be rebuilt after serialization. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 08:56:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Thu, 11 Jun 2009 08:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11584321.1244725016429.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer reopened JBAS-7010:
--------------------------------



Can you check the fix into the EAP branch too? That's the branch we're using for Jopr/EmbJopr dev.



> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 09:01:58 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 11 Jun 2009 09:01:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-989) TCPPING: add new
 member addresses to initial_hosts dynamically
In-Reply-To: <31320194.1244721176847.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19331564.1244725318788.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban resolved JGRP-989.
---------------------------

    Resolution: Done


> TCPPING: add new member addresses to initial_hosts dynamically
> --------------------------------------------------------------
>
>                 Key: JGRP-989
>                 URL: https://jira.jboss.org/jira/browse/JGRP-989
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> When we have A,B and C listed in initial_hosts but later D and E join, and we have a partition {A,B,C} and {D,E}, when the partition heals later, we have no way of merging the 2 subgroups back into 1 because initial_hosts doesn't contain D or E.
> SOLUTION: dynamically add members not in initial_hosts to initial_hosts on view changes. Keep the number of dynamically added members bounded.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 09:21:21 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 11 Jun 2009 09:21:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-205) upgrade to the
	latest xb release
Message-ID: <32952551.1244726484110.JavaMail.jira@cloud.prod.atl2.jboss.com>

upgrade to the latest xb release
--------------------------------

                 Key: JBMETA-205
                 URL: https://jira.jboss.org/jira/browse/JBMETA-205
             Project: JBoss Metadata
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: 1.0.2.Beta2


XB 2.0.2.Beta1 at a minimum.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 09:24:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 11 Jun 2009 09:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-88) ViewUse getting lost
 during serialization
In-Reply-To: <21552121.1244724776829.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28822015.1244726696544.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Emanuel Muckenhuber resolved JBMAN-88.
--------------------------------------

    Fix Version/s: JBossMan.2.1.1.CR1
       Resolution: Done


> ViewUse getting lost during serialization
> -----------------------------------------
>
>                 Key: JBMAN-88
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-88
>             Project: JBoss Managed
>          Issue Type: Bug
>    Affects Versions: JBossMan.2.1.1.Beta3
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossMan.2.1.1.CR1
>
>
> Since the annotations are transient, the ViewUse cannot be rebuilt after serialization. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 09:24:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 11 Jun 2009 09:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-206) TESTSUITE:
 externalize schema to class mapping into a properties file
Message-ID: <10888381.1244726696753.JavaMail.jira@cloud.prod.atl2.jboss.com>

TESTSUITE: externalize schema to class mapping into a properties file
---------------------------------------------------------------------

                 Key: JBMETA-206
                 URL: https://jira.jboss.org/jira/browse/JBMETA-206
             Project: JBoss Metadata
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: 1.0.2.Beta2


All the mapping is currently done in MetaDataSchemaResolverFactory. Working on the metadata split, this class could be in the common but the mapping would be different for a specific subproject.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 09:27:07 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 11 Jun 2009 09:27:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMETA-206) TESTSUITE:
 externalize schema to class mapping into a properties file
In-Reply-To: <10888381.1244726696753.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21969964.1244726827487.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Alexey Loubyansky closed JBMETA-206.
------------------------------------

    Resolution: Done


Done.

> TESTSUITE: externalize schema to class mapping into a properties file
> ---------------------------------------------------------------------
>
>                 Key: JBMETA-206
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-206
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.0.2.Beta2
>
>
> All the mapping is currently done in MetaDataSchemaResolverFactory. Working on the metadata split, this class could be in the common but the mapping would be different for a specific subproject.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 09:32:56 2009
From: jira-events at lists.jboss.org (Victor Starenky (JIRA))
Date: Thu, 11 Jun 2009 09:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <1869123.1244727176884.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Victor Starenky commented on JBMESSAGING-1631:
----------------------------------------------

We've switched to the latest jars for messaging that has fix for  JBMESSAGING-1456 and as well switched all other required libaries including remoting (to the version 2.2.3 as per documentation).
Still this morning we see one node piling up topic messages. As far as I can tell we mostly experience this issue with topics. One or more nodes stop receiving messages and in JMX console we see thousands of them sitting on these nodes.

As I mentioned before we're pushing servers to the limits overnight so timeouts are likely caused by exessive load more than network.

> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 10:00:08 2009
From: jira-events at lists.jboss.org (Zachary Bedell (JIRA))
Date: Thu, 11 Jun 2009 10:00:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-207)
 NullPointerException during
 deployment of EJB3 methods with zero parameters
Message-ID: <31747213.1244728808387.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointerException during deployment of EJB3 methods with zero parameters
---------------------------------------------------------------------------

                 Key: JBMETA-207
                 URL: https://jira.jboss.org/jira/browse/JBMETA-207
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.0.0.GA
         Environment: JBoss-5.1.0-GA, JDK 1.6.0_07-b06-153 (Apple/Sun JVM, 64-bit on OS/X), EJB3 w/ descriptor overrides
            Reporter: Zachary Bedell
            Assignee: Alexey Loubyansky


Deploying an EJB3 based EAR results in an NPE with the below stack trace.  The problem appears to manifest with EJB3's containing methods that take zero arguments.  There are also XML descriptor based attributes for several of the metadata elements.  To the best of my knowledge the descriptors only augment, not override anything specified in annotations.

Patch for this should be trivial (an additional null check on line 83 of RolesAllowedProcessor.java should do it).  I'm in the process of attempting to get JBMETA built from source and integrated into my stack.  Will attach patch & tests unless someone beats me to it.

The stack:

09:44:51,219 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=vfszip:/jboss/jboss-eap-5.0/server/ucmsfc/deploy/ucms.ear/ state=ClassLoader mode=Manual requiredState=PostClassLoader
org.jboss.deployers.spi.DeploymentException: Cannot process metadata
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:181)
	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:93)
	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.install(DeployersImpl.java:1098)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
	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:698)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:59)
	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:355)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
	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:310)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:241)
	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
	at org.jboss.Main.boot(Main.java:216)
	at org.jboss.Main$1.run(Main.java:546)
	at java.lang.Thread.run(Thread.java:637)
Caused by: java.lang.NullPointerException
	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:83)
	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:48)
	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:215)
	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:172)
	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:151)
	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:94)
	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:52)
	at org.jboss.metadata.annotation.creator.AbstractCreator.process(AbstractCreator.java:154)
	at org.jboss.metadata.annotation.creator.AbstractCreator.processMetaData(AbstractCreator.java:87)
	at org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator.create(JBoss50Creator.java:109)
	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processJBossMetaData(OptAnnotationMetaDataDeployer.java:134)
	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processMetaData(OptAnnotationMetaDataDeployer.java:84)
	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:177)
	... 31 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 10:02:56 2009
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Thu, 11 Jun 2009 10:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2118) comment makes
 Work Definition parser fail
Message-ID: <30166236.1244728976467.JavaMail.jira@cloud.prod.atl2.jboss.com>

comment makes Work Definition parser fail
-----------------------------------------

                 Key: JBRULES-2118
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2118
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse (flow)
    Affects Versions: 5.0.1.FINAL
         Environment: Eclipse
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor


See example in Drools Flow, section 8.2.1., Creating the Work Definition: The comment // add more work items here ... makes the parser fail when calling up the RuleFlow editor ("Could not parse work definitions ...: null")


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 10:04:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 11 Jun 2009 10:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMETA-207)
 NullPointerException during
 deployment of EJB3 methods with zero parameters
In-Reply-To: <31747213.1244728808387.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4716605.1244729096611.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Alexey Loubyansky reassigned JBMETA-207:
----------------------------------------

    Assignee: Andrew Lee Rubinger  (was: Alexey Loubyansky)


Andrew, can you look into this?

> NullPointerException during deployment of EJB3 methods with zero parameters
> ---------------------------------------------------------------------------
>
>                 Key: JBMETA-207
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-207
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.0.GA
>         Environment: JBoss-5.1.0-GA, JDK 1.6.0_07-b06-153 (Apple/Sun JVM, 64-bit on OS/X), EJB3 w/ descriptor overrides
>            Reporter: Zachary Bedell
>            Assignee: Andrew Lee Rubinger
>
> Deploying an EJB3 based EAR results in an NPE with the below stack trace.  The problem appears to manifest with EJB3's containing methods that take zero arguments.  There are also XML descriptor based attributes for several of the metadata elements.  To the best of my knowledge the descriptors only augment, not override anything specified in annotations.
> Patch for this should be trivial (an additional null check on line 83 of RolesAllowedProcessor.java should do it).  I'm in the process of attempting to get JBMETA built from source and integrated into my stack.  Will attach patch & tests unless someone beats me to it.
> The stack:
> 09:44:51,219 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=vfszip:/jboss/jboss-eap-5.0/server/ucmsfc/deploy/ucms.ear/ state=ClassLoader mode=Manual requiredState=PostClassLoader
> org.jboss.deployers.spi.DeploymentException: Cannot process metadata
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:181)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:93)
> 	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.install(DeployersImpl.java:1098)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:698)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:59)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:355)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:310)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:241)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 	at org.jboss.Main.boot(Main.java:216)
> 	at org.jboss.Main$1.run(Main.java:546)
> 	at java.lang.Thread.run(Thread.java:637)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:83)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:48)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:215)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:172)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:151)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:94)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:52)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.process(AbstractCreator.java:154)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.processMetaData(AbstractCreator.java:87)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator.create(JBoss50Creator.java:109)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processJBossMetaData(OptAnnotationMetaDataDeployer.java:134)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processMetaData(OptAnnotationMetaDataDeployer.java:84)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:177)
> 	... 31 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 10:15:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 11 Jun 2009 10:15:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1649) redesign
 management replication
Message-ID: <1828892.1244729756776.JavaMail.jira@cloud.prod.atl2.jboss.com>

redesign management replication
-------------------------------

                 Key: JBMESSAGING-1649
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1649
             Project: JBoss Messaging
          Issue Type: Task
    Affects Versions: 2.0.0 Beta
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 2.0.0


In order for management operation using JMX to be replicated, the MBeans are translating the management
operation to a management messages which is sent to the management address using Core API. This allows
for management messages to be properly replicated.

However this allow forces the server to have an acceptor and a connector to talk to *itelsf* which is configusing
and clutter the server configuration.

The management code should be redesigned to be plugged directly on the server-side. The management 
service'd no longer send a Core message using the Core API. Instead it'd call directly the ServerSessionPacketHandler
(or equivalent) to handle a packet corresponding to the management message. It'll work since the handler will then
replicate the packet correctly.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 10:47:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 11 Jun 2009 10:47:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <27683092.1244731677179.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1631:
-----------------------------------------

Thanks Victor. I'll change to topic then. 

A question: when you find the messaging piling up, did you stop the sending and wait to see if the messages are still there? 

Also my sending program just keep sending messages in a loop, 20 messages for each transaction. is that enough to load the servers?

Howard


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 11:23:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Thu, 11 Jun 2009 11:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11296698.1244733837724.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-7010.
---------------------------------

    Resolution: Done


Done
Sending        security/src/main/org/jboss/security/jndi/JndiLoginInitialContextFactory.java
Sending        security/src/main/org/jboss/security/jndi/SecurityAssociationActions.java
Transmitting file data ..
Committed revision 90097.


> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 11:44:57 2009
From: jira-events at lists.jboss.org (Victor Starenky (JIRA))
Date: Thu, 11 Jun 2009 11:44:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <22303782.1244735097326.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Victor Starenky commented on JBMESSAGING-1631:
----------------------------------------------

Messages are sent intermittently, there isn't a huge stream of these. But AllMessageCount is in the order of thousands and only increases with every new message. 

What happens with topics is that some node stops receiving messages. It shows all SubscriptionCounts = 0. Once it gets into this state is stays there.

We created our own monitoring system that records every sent message and every received message into database stamped with the time and machine name. This is how we find these problems.

Also when I was speaking about the load I wasn't talking about JMS load but rather the overall machine load. All servers run a large application that's doing tons of jobs overnight. So this might affect ping timeouts - when machine is too busy to respond in time. This is only a theory though.

> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 11:49:00 2009
From: jira-events at lists.jboss.org (Victor Starenky (JIRA))
Date: Thu, 11 Jun 2009 11:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13658536.1244735340340.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Victor Starenky commented on JBMESSAGING-1456:
----------------------------------------------

Hate to tell but this might have to be reopened. We've just installed new messaging jar together with remoting 2.2.3 and see one message stuck in delivery on one of the queues

> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 12:13:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 11 Jun 2009 12:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1841) Improve logging
 for InterceptorsFactory warning
In-Reply-To: <17265944.1243955516468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16564640.1244736836641.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai updated EJBTHREE-1841:
-----------------------------------

    Affects Version/s: 1.1.6
                           (was: AS 5.0.0.CR1)


> Improve logging for InterceptorsFactory warning
> -----------------------------------------------
>
>                 Key: EJBTHREE-1841
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1841
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: 1.1.6
>         Environment: Windows XP 32-bit, JBoss AS 5.1.0GA
>            Reporter: Ben Abernathy
>            Assignee: jaikiran pai
>
> Every time this section of code is called, the following warning is displayed:
> 09:02:34,655 WARN  [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
> Upon inspecting EJBTHREE-1246, it appears this warning can be ignored by bean developers. If that is the case, is it necessary to fill up the console and log with benign warnings? There can be lots of these if the application is large.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 12:15:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 11 Jun 2009 12:15:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1841) Improve logging
 for InterceptorsFactory warning
In-Reply-To: <17265944.1243955516468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16908474.1244736956593.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai resolved EJBTHREE-1841.
------------------------------------

    Fix Version/s: 1.1.7
       Resolution: Done


Done. The InterceptorsFactory will no longer be used in the core (ejb3-interceptors-aop.xml). 

> Improve logging for InterceptorsFactory warning
> -----------------------------------------------
>
>                 Key: EJBTHREE-1841
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1841
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: 1.1.6
>         Environment: Windows XP 32-bit, JBoss AS 5.1.0GA
>            Reporter: Ben Abernathy
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> Every time this section of code is called, the following warning is displayed:
> 09:02:34,655 WARN  [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
> Upon inspecting EJBTHREE-1246, it appears this warning can be ignored by bean developers. If that is the case, is it necessary to fill up the console and log with benign warnings? There can be lots of these if the application is large.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 12:28:58 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 11 Jun 2009 12:28:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17973080.1244737738730.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1456:
-----------------------------------------

Hi Vitor, 

did you use the new parameters in the remoting config file? 
               <attribute name="failureDisconnectTimeout" isParam="true">0</attribute>
               <attribute name="callbackErrorsAllowed">1</attribute>
               <attribute name="useClientConnectionIdentity" isParam="true">true</attribute>

If you are seeing stuck messages, can you try the messaging jars included in test-1456-jars.zip and upload the logs? The logs can give us a proof of whether the message is stuck for the same reason. Thanks.

Howard


> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 12:32:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 11 Jun 2009 12:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-192) Fix interaction
 between metadata and synch checker
Message-ID: <23074204.1244737976457.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix interaction between metadata and synch checker
--------------------------------------------------

                 Key: JBDEPLOY-192
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-192
             Project: JBoss Deployers
          Issue Type: Bug
          Components: structure
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA


Currently metadata checker is picking up leaves from synch checker.
It should only pick up the same leaves from structure cache as restricted by VFS filter.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 12:50:58 2009
From: jira-events at lists.jboss.org (Victor Starenky (JIRA))
Date: Thu, 11 Jun 2009 12:50:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16885649.1244739058474.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Victor Starenky commented on JBMESSAGING-1456:
----------------------------------------------

Hi Howard,

Yes, we're using the new parameters.
We can't really use the test jars with logging since last time they seemed to cause memory leaks and servers repeatedly ran out of memory.

> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 13:11:56 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 11 Jun 2009 13:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMDR-57) Make MethodSignature
 and DeclaredMethodSignature interchangable in equals and hashCode
Message-ID: <20687081.1244740316458.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make MethodSignature and DeclaredMethodSignature interchangable in equals and hashCode
--------------------------------------------------------------------------------------

                 Key: JBMDR-57
                 URL: https://jira.jboss.org/jira/browse/JBMDR-57
             Project: JBoss MetaData Repository
          Issue Type: Feature Request
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: JBossMDR-2.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 13:11:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 11 Jun 2009 13:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBWEB-144) JSP EL ternary
 operator requires space before colon
Message-ID: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>

JSP EL ternary operator requires space before colon
---------------------------------------------------

                 Key: JBWEB-144
                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossWeb-2.0.0.GA_CP09
            Reporter: Mike Millson
            Assignee: Remy Maucherat


JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:

<c:set var="truevalue" value="true" />
<c:set var="falsevalue" value="false"/>
<c:out value="${not empty param.yes?truevalue:falsevalue}"/>

It throws this error:
2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
       at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)

But this works with a space added before the colon:
<c:out value="${not empty param.yes?truevalue :falsevalue}"/>

This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.

[1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
[2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
[3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 13:16:57 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 11 Jun 2009 13:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMDR-57) Make MethodSignature
 and DeclaredMethodSignature interchangable in equals and hashCode
In-Reply-To: <20687081.1244740316458.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20432074.1244740617146.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Kabir Khan closed JBMDR-57.
---------------------------

    Resolution: Done


> Make MethodSignature and DeclaredMethodSignature interchangable in equals and hashCode
> --------------------------------------------------------------------------------------
>
>                 Key: JBMDR-57
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-57
>             Project: JBoss MetaData Repository
>          Issue Type: Feature Request
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: JBossMDR-2.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 13:20:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 11 Jun 2009 13:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4264874.1244740856550.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-144:
-------------------------------

    Attachment: test.jsp


Reproducer.

> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 13:33:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 11 Jun 2009 13:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24689865.1244741636486.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-144:
-------------------------------

    Component/s: Tomcat


> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 14:02:07 2009
From: jira-events at lists.jboss.org (Zachary Bedell (JIRA))
Date: Thu, 11 Jun 2009 14:02:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-207)
 NullPointerException during
 deployment of EJB3 methods with zero parameters
In-Reply-To: <31747213.1244728808387.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1356284.1244743327357.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Zachary Bedell updated JBMETA-207:
----------------------------------

    Attachment: fixJBMETA207.patch


Fixes this NPE allowing deployment to proceed

> NullPointerException during deployment of EJB3 methods with zero parameters
> ---------------------------------------------------------------------------
>
>                 Key: JBMETA-207
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-207
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.0.GA
>         Environment: JBoss-5.1.0-GA, JDK 1.6.0_07-b06-153 (Apple/Sun JVM, 64-bit on OS/X), EJB3 w/ descriptor overrides
>            Reporter: Zachary Bedell
>            Assignee: Andrew Lee Rubinger
>         Attachments: fixJBMETA207.patch
>
>
> Deploying an EJB3 based EAR results in an NPE with the below stack trace.  The problem appears to manifest with EJB3's containing methods that take zero arguments.  There are also XML descriptor based attributes for several of the metadata elements.  To the best of my knowledge the descriptors only augment, not override anything specified in annotations.
> Patch for this should be trivial (an additional null check on line 83 of RolesAllowedProcessor.java should do it).  I'm in the process of attempting to get JBMETA built from source and integrated into my stack.  Will attach patch & tests unless someone beats me to it.
> The stack:
> 09:44:51,219 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=vfszip:/jboss/jboss-eap-5.0/server/ucmsfc/deploy/ucms.ear/ state=ClassLoader mode=Manual requiredState=PostClassLoader
> org.jboss.deployers.spi.DeploymentException: Cannot process metadata
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:181)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:93)
> 	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.install(DeployersImpl.java:1098)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:698)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:59)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:355)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:310)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:241)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 	at org.jboss.Main.boot(Main.java:216)
> 	at org.jboss.Main$1.run(Main.java:546)
> 	at java.lang.Thread.run(Thread.java:637)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:83)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:48)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:215)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:172)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:151)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:94)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:52)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.process(AbstractCreator.java:154)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.processMetaData(AbstractCreator.java:87)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator.create(JBoss50Creator.java:109)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processJBossMetaData(OptAnnotationMetaDataDeployer.java:134)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processMetaData(OptAnnotationMetaDataDeployer.java:84)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:177)
> 	... 31 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 14:03:56 2009
From: jira-events at lists.jboss.org (Zachary Bedell (JIRA))
Date: Thu, 11 Jun 2009 14:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-207)
 NullPointerException during
 deployment of EJB3 methods with zero parameters
In-Reply-To: <31747213.1244728808387.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7963740.1244743436555.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471762#action_12471762 ] 

Zachary Bedell commented on JBMETA-207:
---------------------------------------

Attached patch fixes this allowing deployment to proceed.  All other unit tests complete successfully with this patch applied.  I'm still having trouble isolating this to fail independent of the rest of JBoss.  I suspect the processing of XML descriptors contributes to the problem.  I'll give it a bit more time before I give up, but unfortunately the object tree for this is a bit above my head at the moment.

> NullPointerException during deployment of EJB3 methods with zero parameters
> ---------------------------------------------------------------------------
>
>                 Key: JBMETA-207
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-207
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.0.GA
>         Environment: JBoss-5.1.0-GA, JDK 1.6.0_07-b06-153 (Apple/Sun JVM, 64-bit on OS/X), EJB3 w/ descriptor overrides
>            Reporter: Zachary Bedell
>            Assignee: Andrew Lee Rubinger
>         Attachments: fixJBMETA207.patch
>
>
> Deploying an EJB3 based EAR results in an NPE with the below stack trace.  The problem appears to manifest with EJB3's containing methods that take zero arguments.  There are also XML descriptor based attributes for several of the metadata elements.  To the best of my knowledge the descriptors only augment, not override anything specified in annotations.
> Patch for this should be trivial (an additional null check on line 83 of RolesAllowedProcessor.java should do it).  I'm in the process of attempting to get JBMETA built from source and integrated into my stack.  Will attach patch & tests unless someone beats me to it.
> The stack:
> 09:44:51,219 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=vfszip:/jboss/jboss-eap-5.0/server/ucmsfc/deploy/ucms.ear/ state=ClassLoader mode=Manual requiredState=PostClassLoader
> org.jboss.deployers.spi.DeploymentException: Cannot process metadata
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:181)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:93)
> 	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.install(DeployersImpl.java:1098)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:698)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:59)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:355)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:310)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:241)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 	at org.jboss.Main.boot(Main.java:216)
> 	at org.jboss.Main$1.run(Main.java:546)
> 	at java.lang.Thread.run(Thread.java:637)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:83)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:48)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:215)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:172)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:151)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:94)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:52)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.process(AbstractCreator.java:154)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.processMetaData(AbstractCreator.java:87)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator.create(JBoss50Creator.java:109)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processJBossMetaData(OptAnnotationMetaDataDeployer.java:134)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processMetaData(OptAnnotationMetaDataDeployer.java:84)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:177)
> 	... 31 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 17:56:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 11 Jun 2009 17:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2119) Support more
 user-friendly time format in timers
Message-ID: <14275268.1244757416414.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support more user-friendly time format in timers
------------------------------------------------

                 Key: JBRULES-2119
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2119
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler (flow), drools-core (flow), drools-eclipse (flow)
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen


Instead of having to specify timer period and delay in milliseconds, we should allow a more user-friendly format like 5s or 3m.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 18:05:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 11 Jun 2009 18:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2120) Dynamic or Ah-Hoc
	node
Message-ID: <13623222.1244757956488.JavaMail.jira@cloud.prod.atl2.jboss.com>

Dynamic or Ah-Hoc node
----------------------

                 Key: JBRULES-2120
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2120
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler (flow), drools-core (flow), drools-eclipse (flow)
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen
             Fix For: FUTURE


An ad-hoc or dynamic node acts as a node container where not all nodes are cleanly connected to each other but they are modeled as separate fragments that are not necessarily linked to each other.  By default, all nodes that do not have an incoming connection would be triggered when the dynamic node is triggered, and the node will wait until all node instances have been completed before continuing.  Different strategies could also allow:
 - (rule or code) constriants that define when certain fragments should be activated
 - the user can add additional node instances at runtime, even though they are not modeled as part of the process, and the node will wait until they are completed as well

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 19:28:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 11 Jun 2009 19:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2121) JavaDialect isn't
 creating unique ids
Message-ID: <30381835.1244762936401.JavaMail.jira@cloud.prod.atl2.jboss.com>

JavaDialect isn't creating unique ids
-------------------------------------

                 Key: JBRULES-2121
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2121
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen
             Fix For: 5.1.0.M1


JavaDialect.getUniqueLegalName(..) should create a new name for a given set of parameters by first checking whether the name already exists in the dialect.
This check was always false as the name it was checking was wrongly constructed.  As a result, duplicate names could be created.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 19:30:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 11 Jun 2009 19:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2121) JavaDialect
 isn't creating unique ids
In-Reply-To: <30381835.1244762936401.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25431041.1244763056460.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Kris Verlaenen resolved JBRULES-2121.
-------------------------------------

    Resolution: Done


Fixed name that is checked

> JavaDialect isn't creating unique ids
> -------------------------------------
>
>                 Key: JBRULES-2121
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2121
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>            Reporter: Kris Verlaenen
>            Assignee: Kris Verlaenen
>             Fix For: 5.1.0.M1
>
>
> JavaDialect.getUniqueLegalName(..) should create a new name for a given set of parameters by first checking whether the name already exists in the dialect.
> This check was always false as the name it was checking was wrongly constructed.  As a result, duplicate names could be created.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 19:49:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 11 Jun 2009 19:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2119) Support more
 user-friendly time format in timers
In-Reply-To: <14275268.1244757416414.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25006663.1244764196422.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Kris Verlaenen resolved JBRULES-2119.
-------------------------------------

    Fix Version/s: 5.1.0.M1
       Resolution: Done


Timers now use a String for delay and period

> Support more user-friendly time format in timers
> ------------------------------------------------
>
>                 Key: JBRULES-2119
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2119
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (flow), drools-core (flow), drools-eclipse (flow)
>            Reporter: Kris Verlaenen
>            Assignee: Kris Verlaenen
>             Fix For: 5.1.0.M1
>
>
> Instead of having to specify timer period and delay in milliseconds, we should allow a more user-friendly format like 5s or 3m.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 22:48:02 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 11 Jun 2009 22:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28927367.1244774882358.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1456:
-----------------------------------------

Hi Victor,

You don't need to use the remoting jar in the zip, which may not be up to date and cause the mem leak. You only need to use the jboss-messaging.jar and jboss-messaging-client.jar. These two jars should be the same as CP08 exception those extra logs.

Thanks
Howard


> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 03:07:56 2009
From: jira-events at lists.jboss.org (Toni Rikkola (JIRA))
Date: Fri, 12 Jun 2009 03:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2053) Date management
In-Reply-To: <21303337.1239356723284.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23812996.1244790476933.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Toni Rikkola reassigned JBRULES-2053:
-------------------------------------

    Assignee: Toni Rikkola  (was: Mark Proctor)


> Date management
> ---------------
>
>                 Key: JBRULES-2053
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2053
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.0.CR1
>            Reporter: Gilles Hestin
>            Assignee: Toni Rikkola
>             Fix For: 5.1.0.M1
>
>
> Date management :
> 1) Date format :
> The format is dd-MMM-yyyy. We should be able to set a different format as for instance dd/mm/yyyy.
> This property  would be set in a properties file.
> 2) Input field
> No date field available.  Plan to add a date field.
> 3) Error report
> if the user fills a wrong date for instance, a message (dialog box) indicates that the user must have a look at the server log file. It's not user-friendly, and how a business analyst can access to the server (especially if the server is WAS on AIX : access right issue) ?
> The error message should be displayed in the dialog box.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 03:11:56 2009
From: jira-events at lists.jboss.org (Toni Rikkola (JIRA))
Date: Fri, 12 Jun 2009 03:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2053) Date management
In-Reply-To: <21303337.1239356723284.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21471805.1244790716525.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Toni Rikkola commented on JBRULES-2053:
---------------------------------------

1. and 3. are something that could use the improvements that you are talking about. Not sure how to do 1. without breaking backwards compatibility.

2. Can you describe the situation where you are missing the date picker? Just in case it is something that we have missed.

> Date management
> ---------------
>
>                 Key: JBRULES-2053
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2053
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.0.CR1
>            Reporter: Gilles Hestin
>            Assignee: Toni Rikkola
>             Fix For: 5.1.0.M1
>
>
> Date management :
> 1) Date format :
> The format is dd-MMM-yyyy. We should be able to set a different format as for instance dd/mm/yyyy.
> This property  would be set in a properties file.
> 2) Input field
> No date field available.  Plan to add a date field.
> 3) Error report
> if the user fills a wrong date for instance, a message (dialog box) indicates that the user must have a look at the server log file. It's not user-friendly, and how a business analyst can access to the server (especially if the server is WAS on AIX : access right issue) ?
> The error message should be displayed in the dialog box.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 03:13:56 2009
From: jira-events at lists.jboss.org (Toni Rikkola (JIRA))
Date: Fri, 12 Jun 2009 03:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2109) Upload of
 Resource to Guvnor
 with multiple "." in file name causes resource type identification issues
In-Reply-To: <20350008.1244124897030.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16926656.1244790836573.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Toni Rikkola reassigned JBRULES-2109:
-------------------------------------

    Assignee: Toni Rikkola  (was: Mark Proctor)


> Upload of Resource to Guvnor with multiple "." in file name causes resource type identification issues
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2109
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2109
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Graham Gear
>            Assignee: Toni Rikkola
>            Priority: Minor
>
> It seems the resource type identification is based on the file suffix of the resource being uploaded but matches against the first, not last "." in the filename to determine the suffix. This causes issue if the resource includes multiple "." which is valid under most file systems. It is also common for model JARs to include a version number with an extra ".", eg:
> application-model-1.0.0.jar
> The issue can be reproduced by uploading a model, DRL, RF etc to the Guvnor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 03:13:56 2009
From: jira-events at lists.jboss.org (Toni Rikkola (JIRA))
Date: Fri, 12 Jun 2009 03:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2110) Upload of
 RuleFlow with ".rf"
 suffix to Guvnor through WebDAV does not get correctly identified as a
 RuleFlow
In-Reply-To: <21846412.1244125437026.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3315942.1244790836778.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Toni Rikkola reassigned JBRULES-2110:
-------------------------------------

    Assignee: Toni Rikkola  (was: Mark Proctor)


> Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2110
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2110
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Graham Gear
>            Assignee: Toni Rikkola
>
> Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow.
> To reproduce, add a *.rf resource through JBoss Dev Studio or WebDAV client (eg cadaver) and see the resource get itemised incorrectly as a *.drl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 03:22:56 2009
From: jira-events at lists.jboss.org (Toni Rikkola (JIRA))
Date: Fri, 12 Jun 2009 03:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1992)
 IllegalArgumetException when using @timestamp?
In-Reply-To: <1359404.1236299422577.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26304875.1244791376750.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Toni Rikkola commented on JBRULES-1992:
---------------------------------------

I doubt that there is any documentation about it. If you want to take a look at this yourself here is the trunk and build instructions:

http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/

https://www.jboss.org/community/wiki/RulesRepositoryBuildInstructions



> IllegalArgumetException when using @timestamp?
> ----------------------------------------------
>
>                 Key: JBRULES-1992
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1992
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (fusion), drools-core (fusion), drools-guvnor
>    Affects Versions: 5.0.0.M5, 5.0.0.CR1
>         Environment: jdk 1.6
>            Reporter: Zoltan Farkas
>            Assignee: Toni Rikkola
>             Fix For: 5.1.0.M1
>
>
> I think problem is with @timestamp, I use GUVNOR to build my package.
> Here is the exception:
> 2009-03-05 19:56:07,891 [http-0.0.0.0-8080-2] ERROR STDERR - com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract org.drools.guvnor.client.rpc.BuilderResult[] org.drools.guvnor
> .client.rpc.RepositoryService.buildPackage(java.lang.String,java.lang.String,boolean) throws com.google.gwt.user.client.rpc.SerializableException' threw an unexpected exception: org.drools.RuntimeDroolsExcep
> tion: java.lang.IllegalArgumentException: argument type mismatch
> 2009-03-05 19:56:07,895 [http-0.0.0.0-8080-2] ERROR STDERR -    at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:360)
> 2009-03-05 19:56:07,895 [http-0.0.0.0-8080-2] ERROR STDERR -    at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:546)
> 2009-03-05 19:56:07,895 [http-0.0.0.0-8080-2] ERROR STDERR -    at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:164)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:86)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.web.ContextFilter$1.process(ContextFilter.java:42)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:53)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.web.ContextFilter.doFilter(ContextFilter.java:37)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 2009-03-05 19:56:07,898 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
> 2009-03-05 19:56:07,898 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> 2009-03-05 19:56:07,898 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> 2009-03-05 19:56:07,898 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
> 2009-03-05 19:56:07,898 [http-0.0.0.0-8080-2] ERROR STDERR -    at java.lang.Thread.run(Thread.java:619)
> 2009-03-05 19:56:07,898 [http-0.0.0.0-8080-2] ERROR STDERR - Caused by: org.drools.RuntimeDroolsException: java.lang.IllegalArgumentException: argument type mismatch
> 2009-03-05 19:56:07,898 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.base.ClassFieldAccessorFactory.getClassFieldReader(ClassFieldAccessorFactory.java:152)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.base.ClassFieldAccessorCache$CacheEntry.getReadAccessor(ClassFieldAccessorCache.java:315)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.base.ClassFieldAccessorCache.getReadAcessor(ClassFieldAccessorCache.java:245)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.base.ClassFieldAccessorStore.wire(ClassFieldAccessorStore.java:379)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.base.ClassFieldAccessorStore.getReader(ClassFieldAccessorStore.java:97)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.base.ClassFieldAccessorStore.getReader(ClassFieldAccessorStore.java:74)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.compiler.PackageBuilder.processTypeDeclarations(PackageBuilder.java:1031)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.compiler.PackageBuilder.mergePackage(PackageBuilder.java:916)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:608)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:284)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.contenthandler.DRLFileContentHandler.compile(DRLFileContentHandler.java:36)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.builder.ContentPackageAssembler.buildAsset(ContentPackageAssembler.java:198)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.builder.ContentPackageAssembler.buildPackage(ContentPackageAssembler.java:178)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.builder.ContentPackageAssembler.<init>(ContentPackageAssembler.java:104)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.builder.ContentPackageAssembler.<init>(ContentPackageAssembler.java:117)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.ServiceImplementation.buildPackage(ServiceImplementation.java:1375)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.ServiceImplementation.buildPackage(ServiceImplementation.java:1359)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at java.lang.reflect.Method.invoke(Method.java:597)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.security.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:157)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.ServiceImplementation_$$_javassist_7.buildPackage(ServiceImplementation_$$_javassist_7.java)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.RepositoryServiceServlet.buildPackage(RepositoryServiceServlet.java:196)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at java.lang.reflect.Method.invoke(Method.java:597)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:527)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    ... 27 more
> 2009-03-05 19:56:07,903 [http-0.0.0.0-8080-2] ERROR STDERR - Caused by: java.lang.IllegalArgumentException: argument type mismatch
> 2009-03-05 19:56:07,903 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 2009-03-05 19:56:07,903 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> 2009-03-05 19:56:07,903 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> 2009-03-05 19:56:07,903 [http-0.0.0.0-8080-2] ERROR STDERR -    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> 2009-03-05 19:56:07,903 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.base.ClassFieldAccessorFactory.getClassFieldReader(ClassFieldAccessorFactory.java:143)
> 2009-03-05 19:56:07,903 [http-0.0.0.0-8080-2] ERROR STDERR -    ... 68 more
> here is my drl:
> package eventprocessor
> import eventprocessor.model.NetworkEvent
> global EventExpertProcessor processor
> declare NetworkEvent
>   	@role( event )
>   	@timestamp( creationTime )
> end
> here is the NetworkEvent code:
> package  eventprocessor.model;
> import java.util.Date;
> /**
>  *
>  * @author zoly
>  */
> public class NetworkEvent {
> 	private String id;
> 	private String description;
> 	private NetworkNode sourceComponent;
> 	private Integer severity;
> 	private Date creationTime;
>     private java.math.BigDecimal locElevation;
>     private java.math.BigDecimal locLongitude;
>     private java.math.BigDecimal locLatitude;
>     /**
>      * @return the id
>      */
>     public String getId()
>     {
>         return id;
>     }
>     /**
>      * @param id the id to set
>      */
>     public void setId(String id)
>     {
>         this.id = id;
>     }
>     /**
>      * @return the description
>      */
>     public String getDescription()
>     {
>         return description;
>     }
>     /**
>      * @param description the description to set
>      */
>     public void setDescription(String description)
>     {
>         this.description = description;
>     }
>     /**
>      * @return the sourceComponent
>      */
>     public NetworkNode getSourceComponent()
>     {
>         return sourceComponent;
>     }
>     /**
>      * @param sourceComponent the sourceComponent to set
>      */
>     public void setSourceComponent(NetworkNode sourceComponent)
>     {
>         this.sourceComponent = sourceComponent;
>     }
>     /**
>      * @return the severity
>      */
>     public Integer getSeverity()
>     {
>         return severity;
>     }
>     /**
>      * @param severity the severity to set
>      */
>     public void setSeverity(Integer severity)
>     {
>         this.severity = severity;
>     }
>     /**
>      * @return the creationTime
>      */
>     public Date getCreationTime()
>     {
>         return creationTime;
>     }
>     /**
>      * @param creationTime the creationTime to set
>      */
>     public void setCreationTime(Date creationTime)
>     {
>         this.creationTime = creationTime;
>     }
>     /**
>      * @return the locElevation
>      */
>     public java.math.BigDecimal getLocElevation()
>     {
>         return locElevation;
>     }
>     /**
>      * @param locElevation the locElevation to set
>      */
>     public void setLocElevation(java.math.BigDecimal locElevation)
>     {
>         this.locElevation = locElevation;
>     }
>     /**
>      * @return the locLongitude
>      */
>     public java.math.BigDecimal getLocLongitude()
>     {
>         return locLongitude;
>     }
>     /**
>      * @param locLongitude the locLongitude to set
>      */
>     public void setLocLongitude(java.math.BigDecimal locLongitude)
>     {
>         this.locLongitude = locLongitude;
>     }
>     /**
>      * @return the locLatitude
>      */
>     public java.math.BigDecimal getLocLatitude()
>     {
>         return locLatitude;
>     }
>     /**
>      * @param locLatitude the locLatitude to set
>      */
>     public void setLocLatitude(java.math.BigDecimal locLatitude)
>     {
>         this.locLatitude = locLatitude;
>     }
>     @Override
>     public boolean equals(Object obj)
>     {
>         if (obj == null)
>         {
>             return false;
>         }
>         if (getClass() != obj.getClass())
>         {
>             return false;
>         }
>         final NetworkEvent other = (NetworkEvent) obj;
>         if ((this.id == null) ? (other.id != null) : !this.id.equals(other.id))
>         {
>             return false;
>         }
>         return true;
>     }
>     @Override
>     public int hashCode()
>     {
>         int hash = 7;
>         hash = 17 * hash + (this.id != null ? this.id.hashCode() : 0);
>         return hash;
>     }
>     public String toString()
>     {
>         StringBuilder toStringBuilder = new StringBuilder();
>         toStringBuilder.append(super.toString());
>         toStringBuilder.append("\n");
>         toStringBuilder.append("\nid: ");
>         toStringBuilder.append(id);
>         toStringBuilder.append("\ndescription: ");
>         toStringBuilder.append(description);
>         toStringBuilder.append("\nsourceComponent: ");
>         toStringBuilder.append(sourceComponent);
>         toStringBuilder.append("\nseverity: ");
>         toStringBuilder.append(severity);
>         toStringBuilder.append("\ncreationTime: ");
>         toStringBuilder.append(creationTime);
>         toStringBuilder.append("\nlocElevation: ");
>         toStringBuilder.append(locElevation);
>         toStringBuilder.append("\nlocLongitude: ");
>         toStringBuilder.append(locLongitude);
>         toStringBuilder.append("\nlocLatitude: ");
>         toStringBuilder.append(locLatitude);
>         return toStringBuilder.toString();
>     }
>     
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 03:49:57 2009
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 12 Jun 2009 03:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-2421) tomahawk
 doesn't see users's roles
In-Reply-To: <31888261.1244644076879.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25769179.1244792997320.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Thomas Heute resolved JBPORTAL-2421.
------------------------------------

    Resolution: Rejected


> tomahawk doesn't see users's roles
> ----------------------------------
>
>                 Key: JBPORTAL-2421
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2421
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Security
>    Affects Versions: 2.7.2 Final
>            Reporter: Penkov Vladimir
>
> Create user, give him 'User' role. 
> Create jsf portlet with jsfbridge. Add to some page:
> <t:commandLink ... enabledOnUserRole="User">
> Authenticate as created user. Visit this page. Link will always be disabled.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 04:30:58 2009
From: jira-events at lists.jboss.org (Daan Van Heghe (JIRA))
Date: Fri, 12 Jun 2009 04:30:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6549) Investigate
 increased memory requirements and deployment time
In-Reply-To: <5128231.1235670884495.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28847753.1244795458895.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Daan Van Heghe commented on JBAS-6549:
--------------------------------------

I have the exact same problems as : 150 EJBs, 1.8Gb virtual memory used (on WindowsXP), startup time 3m30'
I used 4.0.5 before : 800Mb VM used, startup time 1m15'


> Investigate increased memory requirements and deployment time
> -------------------------------------------------------------
>
>                 Key: JBAS-6549
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6549
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.0.GA, JBossAS-5.0.1.GA
>            Reporter: Dimitris Andreadis
>            Assignee: Ales Justin
>         Attachments: AS 5_x profiler snapshot.zip
>
>
> A user reported x2 increase in deployment time and x4 increase in memory usage when moving an application from JBoss 4.2 -> 5.x.
> We need to investigate how to improve both the memory usage and the deployment time.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 04:38:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 04:38:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1848) Remove
 INFO-level logging in EndpointDeployer
In-Reply-To: <23793204.1244795937434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16444970.1244795937586.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger resolved EJBTHREE-1848.
-------------------------------------------

    Resolution: Done


> Remove INFO-level logging in EndpointDeployer
> ---------------------------------------------
>
>                 Key: EJBTHREE-1848
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1848
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: endpoint-deployers
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.7
>
>
> This should go to DEBUG:
> 23:18:05,567 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 6687ec13{name=jboss.j2ee:jar=p
> rofileservice-secured.jar,name=SecureDeploymentManager,service=EJB3_endpoint bean=org.jboss.ejb3.end
> point.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
> ..as to not spam the console.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 04:38:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 04:38:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1848) Remove
 INFO-level logging in EndpointDeployer
Message-ID: <23793204.1244795937434.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remove INFO-level logging in EndpointDeployer
---------------------------------------------

                 Key: EJBTHREE-1848
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1848
             Project: EJB 3.0
          Issue Type: Task
          Components: endpoint-deployers
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.1.7


This should go to DEBUG:

23:18:05,567 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 6687ec13{name=jboss.j2ee:jar=p
rofileservice-secured.jar,name=SecureDeploymentManager,service=EJB3_endpoint bean=org.jboss.ejb3.end
point.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}

..as to not spam the console.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 04:43:08 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 04:43:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1849) Update
 dependency chain for Plugin 1.1.7 Release
Message-ID: <17075972.1244796188455.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update dependency chain for Plugin 1.1.7 Release
------------------------------------------------

                 Key: EJBTHREE-1849
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1849
             Project: EJB 3.0
          Issue Type: Task
            Reporter: Andrew Lee Rubinger
            Assignee: jaikiran pai
             Fix For: 1.1.7


Container task to track commits to update the dependency chain for the EJB3 Plugin 1.1.7 release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 04:48:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 12 Jun 2009 04:48:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1849) Update
 dependency chain for Plugin 1.0.9 Release
In-Reply-To: <17075972.1244796188455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10905289.1244796537075.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai updated EJBTHREE-1849:
-----------------------------------

        Summary: Update dependency chain for Plugin 1.0.9 Release  (was: Update dependency chain for Plugin 1.1.7 Release)
    Description: Container task to track commits to update the dependency chain for the EJB3 Plugin 1.0.9 release  (was: Container task to track commits to update the dependency chain for the EJB3 Plugin 1.1.7 release)


> Update dependency chain for Plugin 1.0.9 Release
> ------------------------------------------------
>
>                 Key: EJBTHREE-1849
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1849
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Andrew Lee Rubinger
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> Container task to track commits to update the dependency chain for the EJB3 Plugin 1.0.9 release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 05:07:56 2009
From: jira-events at lists.jboss.org (Fred Bricon (JIRA))
Date: Fri, 12 Jun 2009 05:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6870) Error deploying
 JavaEE application which uses Ehcache
In-Reply-To: <25356047.1241615736766.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25758494.1244797676900.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Fred Bricon commented on JBAS-6870:
-----------------------------------

Hi,

this issue is dicussed [here|http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4194999#4194999]. Basically the persistence name scheme has changed between JBoss AS 4.x and 5.x, and is incompatible with ehCache.

Any workaround advised? (write a custom CacheProvider, use another caching technology)
I can't imagine noone is using AS 5 in combination ehcache w/ hibernate

regards,

Fred Bricon

> Error deploying JavaEE application which uses Ehcache
> -----------------------------------------------------
>
>                 Key: JBAS-6870
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6870
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: JDK 1.5.0_11
> JBoss AS 5.0.1.GA
>            Reporter: Rainer Flicker
>
> Deploying a JavaEE application (EAR), which uses hibernate 3.3.1, JBoss Seam 2.1.1 and Ehcache 1.5.0 results in following error
> (works with JBoss AS 4.2.3.GA):
> 2009-05-06 14:59:14,095 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Start: name=persistence.unit:unitName=asms.ear/asms.jar#asms state=Create
> java.lang.IllegalArgumentException: Cache name cannot contain '/' characters.
> 	at net.sf.ehcache.config.CacheConfiguration.setName(CacheConfiguration.java:163)
> 	at net.sf.ehcache.Cache.setName(Cache.java:1721)
> 	at net.sf.ehcache.CacheManager.addCache(CacheManager.java:632)
> 	at net.sf.ehcache.hibernate.EhCacheProvider.buildCache(EhCacheProvider.java:90)
> 	at org.hibernate.cache.impl.bridge.RegionFactoryCacheProviderBridge.buildEntityRegion(RegionFactoryCacheProviderBridge.java:96)
> 	at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:255)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1327)
> 	at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:867)
> 	at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:669)
> 	at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:132)
> 	at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:301)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
> 	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:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:698)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
> 	at org.jboss.Main.boot(Main.java:209)
> 	at org.jboss.Main$1.run(Main.java:547)
> 	at java.lang.Thread.run(Thread.java:595)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 05:43:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 12 Jun 2009 05:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1841) Improve logging
 for InterceptorsFactory warning
In-Reply-To: <17265944.1243955516468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21509221.1244799836583.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai updated EJBTHREE-1841:
-----------------------------------

    Component/s: core


> Improve logging for InterceptorsFactory warning
> -----------------------------------------------
>
>                 Key: EJBTHREE-1841
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1841
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core
>    Affects Versions: 1.1.6
>         Environment: Windows XP 32-bit, JBoss AS 5.1.0GA
>            Reporter: Ben Abernathy
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> Every time this section of code is called, the following warning is displayed:
> 09:02:34,655 WARN  [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
> Upon inspecting EJBTHREE-1246, it appears this warning can be ignored by bean developers. If that is the case, is it necessary to fill up the console and log with benign warnings? There can be lots of these if the application is large.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 05:43:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 12 Jun 2009 05:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1838) Fix the
	MultipleEarTestCase
In-Reply-To: <29605108.1243237929207.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25231756.1244799836727.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai updated EJBTHREE-1838:
-----------------------------------

    Component/s: testsuite


> Fix the MultipleEarTestCase
> ---------------------------
>
>                 Key: EJBTHREE-1838
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1838
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: testsuite
>    Affects Versions: 1.1.6
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> The org.jboss.ejb3.test.persistenceunits.unit.MultipleEarTestCase depends on the contents of the error message in the exception stacktrace, to test that the deployment failed because of the expected issue. The error message have been made more user friendly as part of EJBTHREE-1815 which causes this test case to fail. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 05:45:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 12 Jun 2009 05:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1849) Update
 dependency chain for Plugin 1.0.9 Release
In-Reply-To: <17075972.1244796188455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1332401.1244799956543.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai updated EJBTHREE-1849:
-----------------------------------

    Component/s: plugin


> Update dependency chain for Plugin 1.0.9 Release
> ------------------------------------------------
>
>                 Key: EJBTHREE-1849
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1849
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: plugin
>            Reporter: Andrew Lee Rubinger
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> Container task to track commits to update the dependency chain for the EJB3 Plugin 1.0.9 release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:04:56 2009
From: jira-events at lists.jboss.org (Martin Vecera (JIRA))
Date: Fri, 12 Jun 2009 06:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2122) SchedulerTest too
	impatient
Message-ID: <14208199.1244801096472.JavaMail.jira@cloud.prod.atl2.jboss.com>

SchedulerTest too impatient
---------------------------

                 Key: JBRULES-2122
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2122
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 4.0.7
            Reporter: Martin Vecera
            Assignee: Mark Proctor


On line 184 in org/drools/reteoo/SchedulerTest.java is a sleep for a data structure to get filled. On some machines, the half second sleep is not sufficient and the tast permanently fails with data.size() == 3 instead of 4.

Could the sleep be prolonged at least to one second?

The drawback of this failure is SOA Platform certification on HP-UX IA64. We have to manually edit the sleep and rerun the test. This slows down the QE process.

Actually, I got the problem with https://svn.jboss.org/repos/labs/labs/jbossrules/soa_tags/4.3.0.GA_IR1/ but it would affect more versions than just 4.0.7 IMHO. Could you please edit the "Affects Version/s" field to all potential versions? Many thanks!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:08:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 06:08:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1647) Correct
 system property
 name in JBMBootstrapServer, add setting of property to start script, add
 config dir to stop script.
In-Reply-To: <29497109.1244665316669.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32874824.1244801337104.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1647:
---------------------------------

    Fix Version/s: 2.0.0.beta2
                       (was: 2.0.0)


> Correct system property name in JBMBootstrapServer, add setting of property to start script, add config dir to stop script.
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1647
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1647
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Scott Clasen
>            Assignee: Andy Taylor
>             Fix For: 2.0.0.beta2
>
>
> Line 88 of JBMBootstrapServer  is
> String dirName = System.getProperty("jbm.bootsrap.bin.dir", ".");
> Property should be jbm.bootstrap.bin.dir instead of jbm.bootsrap.bin.dir?
> Also the start and stop scripts in the bin dir should probably work by setting this property based on the config dir you use, so KILL_ME gets touched in the config dir
> So run.sh should set -Djbm.bootstrap.bin.dir=$CONFIG_DIR
> and stop.sh should capture $1 as $CONFIG_DIR and  touch $CONFIG_DIR/KILL_ME
> otherwise if you are running 2 configs out of the same distro...like
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/one &
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/two &
> CURRENT 
> /messaging-2.0.0.BETA1/bin/stop.sh  
>  //-->BRINGS DOWN BOTH SERVERS
> CHANGED
> /messaging-2.0.0.BETA1/bin/stop.sh /path/to/config/one 
> //-->Brings down only server one

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:08:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 06:08:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22761142.1244801337901.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox updated JBMESSAGING-1646:
---------------------------------

    Fix Version/s: 2.0.0.beta2
                       (was: 2.0.0)


> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>         Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>             Fix For: 2.0.0.beta2
>
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:08:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 06:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1647) Correct
 system property
 name in JBMBootstrapServer, add setting of property to start script, add
 config dir to stop script.
In-Reply-To: <29497109.1244665316669.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14377792.1244801336844.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox reopened JBMESSAGING-1647:
----------------------------------



> Correct system property name in JBMBootstrapServer, add setting of property to start script, add config dir to stop script.
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1647
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1647
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Scott Clasen
>            Assignee: Andy Taylor
>             Fix For: 2.0.0.beta2
>
>
> Line 88 of JBMBootstrapServer  is
> String dirName = System.getProperty("jbm.bootsrap.bin.dir", ".");
> Property should be jbm.bootstrap.bin.dir instead of jbm.bootsrap.bin.dir?
> Also the start and stop scripts in the bin dir should probably work by setting this property based on the config dir you use, so KILL_ME gets touched in the config dir
> So run.sh should set -Djbm.bootstrap.bin.dir=$CONFIG_DIR
> and stop.sh should capture $1 as $CONFIG_DIR and  touch $CONFIG_DIR/KILL_ME
> otherwise if you are running 2 configs out of the same distro...like
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/one &
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/two &
> CURRENT 
> /messaging-2.0.0.BETA1/bin/stop.sh  
>  //-->BRINGS DOWN BOTH SERVERS
> CHANGED
> /messaging-2.0.0.BETA1/bin/stop.sh /path/to/config/one 
> //-->Brings down only server one

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:14:56 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 12 Jun 2009 06:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1650) The
 standalone clustered
 config uses property substitution in the beans file
In-Reply-To: <23696594.1244801696672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23297650.1244801696914.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andy Taylor reassigned JBMESSAGING-1650:
----------------------------------------

    Assignee: Andy Taylor  (was: Tim Fox)


> The standalone clustered config uses property substitution in the beans file
> ----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1650
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1650
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>             Fix For: 2.0.0.beta2
>
>
> The standalone clustered config uses property substitution in the beans file but supplies no defaults. This means that starting the server always falls over

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:16:56 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 12 Jun 2009 06:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1651) the standalone
 server
 creates the logs and data dir in the bin dir. this should be in the root
 dir
In-Reply-To: <25796726.1244801816594.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23647858.1244801816938.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andy Taylor closed JBMESSAGING-1651.
------------------------------------

    Resolution: Done


fixed

> the standalone server creates the logs and data dir in the bin dir. this should be in the root dir
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1651
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1651
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>             Fix For: 2.0.0.beta2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:16:56 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 12 Jun 2009 06:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1651) the
 standalone server
 creates the logs and data dir in the bin dir. this should be in the root
 dir
Message-ID: <25796726.1244801816594.JavaMail.jira@cloud.prod.atl2.jboss.com>

the standalone server creates the logs and data dir in the bin dir. this should be in the root dir
--------------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1651
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1651
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0 Beta1
            Reporter: Andy Taylor
            Assignee: Andy Taylor
             Fix For: 2.0.0.beta2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:20:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 06:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1647) Correct system
 property
 name in JBMBootstrapServer, add setting of property to start script, add
 config dir to stop script.
In-Reply-To: <29497109.1244665316669.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32108972.1244802056627.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox closed JBMESSAGING-1647.
--------------------------------

    Resolution: Done


> Correct system property name in JBMBootstrapServer, add setting of property to start script, add config dir to stop script.
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1647
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1647
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Scott Clasen
>            Assignee: Andy Taylor
>             Fix For: 2.0.0.beta2
>
>
> Line 88 of JBMBootstrapServer  is
> String dirName = System.getProperty("jbm.bootsrap.bin.dir", ".");
> Property should be jbm.bootstrap.bin.dir instead of jbm.bootsrap.bin.dir?
> Also the start and stop scripts in the bin dir should probably work by setting this property based on the config dir you use, so KILL_ME gets touched in the config dir
> So run.sh should set -Djbm.bootstrap.bin.dir=$CONFIG_DIR
> and stop.sh should capture $1 as $CONFIG_DIR and  touch $CONFIG_DIR/KILL_ME
> otherwise if you are running 2 configs out of the same distro...like
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/one &
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/two &
> CURRENT 
> /messaging-2.0.0.BETA1/bin/stop.sh  
>  //-->BRINGS DOWN BOTH SERVERS
> CHANGED
> /messaging-2.0.0.BETA1/bin/stop.sh /path/to/config/one 
> //-->Brings down only server one

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:30:56 2009
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 12 Jun 2009 06:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-123) Use QA databases for
 sql scripts creation
In-Reply-To: <4718364.1243587716425.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26997651.1244802656558.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Boleslaw Dawidowicz resolved JBID-123.
--------------------------------------

    Resolution: Done


> Use QA databases for sql scripts creation
> -----------------------------------------
>
>                 Key: JBID-123
>                 URL: https://jira.jboss.org/jira/browse/JBID-123
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Boleslaw Dawidowicz
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.CR1
>
>
> Distro module should use QA databases to generate schema sql scripts instead of local urls. This will let to generate whole range of sql scripts for all currently tested DBs during release process.
> QA database setup is specified in those files:
> http://anonsvn.jboss.org/repos/jbossidentity/idm/tags/1.0.0.Alpha7/idm-testsuite/src/test/resources/datasources/datasources.xml
> http://anonsvn.jboss.org/repos/jbossidentity/idm/tags/1.0.0.Alpha7/idm-testsuite/src/test/resources/datasources/hibernates.xml

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:53:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Fri, 12 Jun 2009 06:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-192) Fix interaction
 between metadata and synch checker
In-Reply-To: <23074204.1244737976457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12340665.1244804036498.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBDEPLOY-192.
----------------------------------

    Resolution: Done


Fixed in Deployers trunk.

> Fix interaction between metadata and synch checker
> --------------------------------------------------
>
>                 Key: JBDEPLOY-192
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-192
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: structure
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>
> Currently metadata checker is picking up leaves from synch checker.
> It should only pick up the same leaves from structure cache as restricted by VFS filter.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 07:40:56 2009
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 12 Jun 2009 07:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-97) Test with LDAP servers
 matrix in hudson
In-Reply-To: <27637113.1242040006361.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17207559.1244806856518.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Boleslaw Dawidowicz updated JBID-97:
------------------------------------

    Fix Version/s: idm-1.1.0.Alpha1
                       (was: idm-1.0.0.GA)


> Test with LDAP servers matrix in hudson
> ---------------------------------------
>
>                 Key: JBID-97
>                 URL: https://jira.jboss.org/jira/browse/JBID-97
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Boleslaw Dawidowicz
>            Assignee: Boleslaw Dawidowicz
>             Fix For: idm-1.1.0.Alpha1
>
>
> Automated testing in hudson should be performed against (at least):
> - OpenLDAP
> - OpenDS
> - RedHat Directory Server
> - Sun Directory Server
> - Microsoft Active Directory

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 07:46:56 2009
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 12 Jun 2009 07:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-107) LDAPIdentityStoreImpl
 missing features
In-Reply-To: <26311352.1242125507014.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8187847.1244807216548.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Boleslaw Dawidowicz updated JBID-107:
-------------------------------------

    Fix Version/s: idm-1.1.0.Alpha1
                       (was: idm-1.0.0.CR1)


> LDAPIdentityStoreImpl missing features
> --------------------------------------
>
>                 Key: JBID-107
>                 URL: https://jira.jboss.org/jira/browse/JBID-107
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Boleslaw Dawidowicz
>            Assignee: Boleslaw Dawidowicz
>             Fix For: idm-1.1.0.Alpha1
>
>
> Missing features
> - Use external JNDI
> - Custom pluggable JNDI provider (SPI). Will enable to add small features like connection credentials encoding and etc.
> - Page control (keep cookie with additional query data in session context and pray that following query will fit...)
> - Inverse membership search (using memberOf attribute)
> - Make Search and Page control criticality optional

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 08:19:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 08:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1652) Convert build
 to use Maven repository
Message-ID: <20391798.1244809196438.JavaMail.jira@cloud.prod.atl2.jboss.com>

Convert build to use Maven repository
-------------------------------------

                 Key: JBMESSAGING-1652
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1652
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
            Assignee: Tim Fox
             Fix For: 2.0.0


We should convert the build to use the Maven repository and Maven dependency checking rather than the old JBoss Repository.

The rest of the build can stay with ant.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 08:31:56 2009
From: jira-events at lists.jboss.org (Dave Lindquist (JIRA))
Date: Fri, 12 Jun 2009 08:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-5980)
 DeploymentException: No
 Attribute found with name: PolicyConfigurationFacadeMBean
In-Reply-To: <29599323.1222078281210.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23278310.1244809916715.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Dave Lindquist commented on JBAS-5980:
--------------------------------------

Just to add some follow-up to this item...

I also encountered this problem, trying to move from 4.2.2 to 5.1.0.

The problem was a badly packaged EAR file -- JBoss 5 is not as 'forgiving' as 4 in this respect.

Basically, I had an EAR file that contained an EJB JAR and a WAR.  The packaging errors were:
1. All of the classes (servlet included) were packaged into the JAR, instead of properly dispersed (ie, servlet classes in the WAR).
2. The library JARs made use of were all inside the JAR, instead of inside the lib directory of the EAR.
3. I had no ejb-jar.xml file in the JAR.
(and I believe that there were some other little items as well)

Bottom line is, package the EAR file in a proper and approved fashion, and this problem will go away.


> DeploymentException: No Attribute found with name: PolicyConfigurationFacadeMBean
> ---------------------------------------------------------------------------------
>
>                 Key: JBAS-5980
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5980
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: Windows XP SP2, Sun Java 1.5.0_16-b02, JBossAS-5.0.0.CR2, EJB3, Struts 1.3.8
>            Reporter: Rene Leonhardt
>            Assignee: Ales Justin
>
> I have a Struts 1.3.8 and EJB 3.0 application which works just fine in JBoss 4.2.3 but JBoss 5.0.0.CR2 gives many errors when I deploy the EAR (and make the necessary changes to the default configuration):
> 2008-09-22 11:43:45,546 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) Unable to retrieve orb
> javax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
>     at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:559)
>     at org.jboss.web.tomcat.service.deployers.TomcatDeployment$EncListener.lifecycleEvent(TomcatDeployment.java:508)
> 2008-09-22 11:43:47,265 DEBUG [org.jboss.messaging.core.impl.JDBCSupport] (main) Failed to execute: CREATE TABLE JBM_USER (USER_ID VARCHAR(32) NOT NULL, PASSWD VARCHAR(32) NOT NULL, CLIENTID VARCHAR(128), PRIMARY KEY(USER_ID))
> java.sql.SQLException: Table already exists: JBM_USER in statement [CREATE TABLE JBM_USER]
>     at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
>     at org.hsqldb.jdbc.jdbcStatement.fetchResult(Unknown Source)
>     at org.hsqldb.jdbc.jdbcStatement.executeUpdate(Unknown Source)
>     at org.jboss.resource.adapter.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:249)
>     at org.jboss.messaging.core.impl.JDBCSupport.createSchema(JDBCSupport.java:301)
>     at org.jboss.messaging.core.impl.JDBCSupport.start(JDBCSupport.java:167)
>     at org.jboss.jms.server.plugin.JDBCJMSUserManager.start(JDBCJMSUserManager.java:98)
>     at org.jboss.jms.server.plugin.JDBCJMSUserManagerService.startService(JDBCJMSUserManagerService.java:78)
>     at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
>     at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)
> 2008-09-22 11:43:54,296 INFO  [org.hibernate.connection.ConnectionProviderFactory] (main) Initializing connection provider: org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider
> 2008-09-22 11:43:54,296 INFO  [org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider] (main) Using provided datasource
> 2008-09-22 11:43:54,296 DEBUG [org.jboss.util.NestedThrowable] (main) org.jboss.util.NestedThrowable.parentTraceEnabled=true
> 2008-09-22 11:43:54,296 DEBUG [org.jboss.util.NestedThrowable] (main) org.jboss.util.NestedThrowable.nestedTraceEnabled=false
> 2008-09-22 11:43:54,296 DEBUG [org.jboss.util.NestedThrowable] (main) org.jboss.util.NestedThrowable.detectDuplicateNesting=true
> 2008-09-22 11:43:54,296 WARN  [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (main) Throwable while attempting to get a new connection: null
> org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (org.jboss.resource.JBossResourceException: Failed to register driver for: oracle.jdbc.driver.OracleDriver; - nested throwable: (java.lang.ClassNotFoundException: oracle.jdbc.driver.OracleDriver from BaseClassLoader at be4d44{VFSClassLoaderPolicy at 1c2df08{name=vfszip:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear domain=ClassLoaderDomain at 14562c5{name=DefaultDomain parentPolicy=BEFORE parent=org.jboss.system.NoAnnotationURLClassLoader at 1e13d52} roots=[MemoryContextHandler at 12618553[path= context=vfsmemory://1l1k2t1k-f8xjnv-flewujwc-1-flewuvyt-1s real=vfsmemory://1l1k2t1k-f8xjnv-flewujwc-1-flewuvyt-1s], DelegatingHandler at 16021684[path=myapplication.ear context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear], DelegatingHandler at 2135767[path=myapplication.ear/myapplication-ejb.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplication-ejb.jar], DelegatingHandler at 26153692[path=myapplication.ear/myapplicationFramework.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplicationFramework.jar], DelegatingHandler at 2050852[path=myapplication.ear/myapplicationVO.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplicationVO.jar], DelegatingHandler at 8271067[path=myapplication.ear/mysql-connector-java-5.1.6-bin.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/mysql-connector-java-5.1.6-bin.jar], DelegatingHandler at 29371829[path=myapplication.ear/tibjms.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/tibjms.jar], DelegatingHandler at 33093423[path=myapplication.ear/jakarta-oro-2.0.8.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/jakarta-oro-2.0.8.jar], DelegatingHandler at 2904191[path=myapplication.ear/castor-1.1.1.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/castor-1.1.1.jar], ZipEntryHandler at 22602435[path=myapplication.ear/myapplication-ejb.jar/config context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplication-ejb.jar/config]]  delegates=null exported=[com.tibco.tibjms.naming, org.exolab.castor.jdo.oql, org.exolab.castor.util.dialog, org.exolab.castor.gui.images, org.exolab.castor.dsml.tools, com.mysql.jdbc, org.castor.persist.resolver, org.exolab.castor.xml.schema.reader, com.mysql.jdbc.util, org.exolab.castor.tools, org.castor.cache.simple, org.exolab.castor, com.mysql.jdbc.log, org.castor.transactionmanager, org.exolab.castor.xml.validators, org.gjt.mm.mysql, org.apache.oro.text.regex, com.tibco.tibjms, org.exolab.castor.types, org.exolab.castor.util.resources, org.castor.jdo.engine, org.apache.oro.util, org.apache.oro.text.perl, org.exolab.castor.dsml.mozilla, org.castor.cache.distributed, org.exolab.castor.xml.schema, com.tibco.tibjms.naming.tibjmsnaming, com.mysql.jdbc.configs, org.exolab.castor.persist, org.exolab.castor.core.exceptions, org.castor.jdo.conf, org.exolab.castor.net.util, org.exolab.castor.jdo.engine, org.exolab.castor.xml.schema.util, org.exolab.castor.mapping.loader, org.castor.util.concurrent, org.exolab.castor.jdo.drivers, org.castor, org.exolab.castor.xml.descriptors, org.exolab.castor.mapping.xml.types, org.exolab.castor.mapping.handlers, org.castor.jdo.util, com.mysql.jdbc.jdbc2.optional, org.exolab.castor.dsml, com.mysql.jdbc.profiler, org.exolab.castor.xml.schema.writer, org.exolab.castor.jdo.keygen, org.exolab.castor.xml.wls8, org.exolab.castor.dsml.jndi, com.mysql.jdbc.exceptions.jdbc4, org.exolab.castor.gui, org.castor.persist.cache, org.exolab.castor.xml.util, org.exolab.castor.util, org.exolab.castor.xml.dtd.parser, META-INF, org.exolab.castor.mapping, org.exolab.castor.xml.location, org.castor.cache.hashbelt, org.apache.oro.text, com.mysql.jdbc.exceptions, org.exolab.castor.xml, META-INF.services, org.exolab.castor.jdo, org.castor.cache.hashbelt.container, org.exolab.castor.persist.spi, org.exolab.castor.dtx, org.exolab.castor.xml.schema.simpletypes, org.castor.persist, org.apache.oro.text.awk, org.apache.oro.io, org.castor.cache, com.mysql.jdbc.integration.jboss, org.exolab.castor.xml.schema.simpletypes.factory, org.exolab.castor.xml.handlers, org.castor.jdo.drivers, org.exolab.castor.xml.dtd, com.mysql.jdbc.integration.c3p0, org.exolab.castor.net, org.castor.util, org.castor.cache.hashbelt.reaper, org.exolab.castor.dsml.schema, org.castor.mapping, org.castor.persist.proxy, org.exolab.castor.mapping.xml, com.mysql.jdbc.interceptors, ] <IMPORT-ALL>NON_EMPTY}}))
>     at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:225)
>     at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:195)
>     at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:611)
>     at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:257)
>     at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:607)
>     at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:354)
>     at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:381)
>     at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:409)
>     at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:854)
>     at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
>     at org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.getConnection(InjectedDataSourceConnectionProvider.java:46)
>     at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:111)
>     at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2101)
>     at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1325)
>     at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:867)
>     at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:669)
>     at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:132)
>     at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:281)
> Caused by: java.lang.ClassNotFoundException: oracle.jdbc.driver.OracleDriver from BaseClassLoader at be4d44{VFSClassLoaderPolicy at 1c2df08{name=vfszip:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear domain=ClassLoaderDomain at 14562c5{name=DefaultDomain parentPolicy=BEFORE parent=org.jboss.system.NoAnnotationURLClassLoader at 1e13d52} roots=[MemoryContextHandler at 12618553[path= context=vfsmemory://1l1k2t1k-f8xjnv-flewujwc-1-flewuvyt-1s real=vfsmemory://1l1k2t1k-f8xjnv-flewujwc-1-flewuvyt-1s], DelegatingHandler at 16021684[path=myapplication.ear context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear], DelegatingHandler at 2135767[path=myapplication.ear/myapplication-ejb.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplication-ejb.jar], DelegatingHandler at 26153692[path=myapplication.ear/myapplicationFramework.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplicationFramework.jar], DelegatingHandler at 2050852[path=myapplication.ear/myapplicationVO.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplicationVO.jar], DelegatingHandler at 8271067[path=myapplication.ear/mysql-connector-java-5.1.6-bin.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/mysql-connector-java-5.1.6-bin.jar], DelegatingHandler at 29371829[path=myapplication.ear/tibjms.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/tibjms.jar], DelegatingHandler at 33093423[path=myapplication.ear/jakarta-oro-2.0.8.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/jakarta-oro-2.0.8.jar], DelegatingHandler at 2904191[path=myapplication.ear/castor-1.1.1.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/castor-1.1.1.jar], ZipEntryHandler at 22602435[path=myapplication.ear/myapplication-ejb.jar/config context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplication-ejb.jar/config]]  delegates=null exported=[com.tibco.tibjms.naming, org.exolab.castor.jdo.oql, org.exolab.castor.util.dialog, org.exolab.castor.gui.images, org.exolab.castor.dsml.tools, com.mysql.jdbc, org.castor.persist.resolver, org.exolab.castor.xml.schema.reader, com.mysql.jdbc.util, org.exolab.castor.tools, org.castor.cache.simple, org.exolab.castor, com.mysql.jdbc.log, org.castor.transactionmanager, org.exolab.castor.xml.validators, org.gjt.mm.mysql, org.apache.oro.text.regex, com.tibco.tibjms, org.exolab.castor.types, org.exolab.castor.util.resources, org.castor.jdo.engine, org.apache.oro.util, org.apache.oro.text.perl, org.exolab.castor.dsml.mozilla, org.castor.cache.distributed, org.exolab.castor.xml.schema, com.tibco.tibjms.naming.tibjmsnaming, com.mysql.jdbc.configs, org.exolab.castor.persist, org.exolab.castor.core.exceptions, org.castor.jdo.conf, org.exolab.castor.net.util, org.exolab.castor.jdo.engine, org.exolab.castor.xml.schema.util, org.exolab.castor.mapping.loader, org.castor.util.concurrent, org.exolab.castor.jdo.drivers, org.castor, org.exolab.castor.xml.descriptors, org.exolab.castor.mapping.xml.types, org.exolab.castor.mapping.handlers, org.castor.jdo.util, com.mysql.jdbc.jdbc2.optional, org.exolab.castor.dsml, com.mysql.jdbc.profiler, org.exolab.castor.xml.schema.writer, org.exolab.castor.jdo.keygen, org.exolab.castor.xml.wls8, org.exolab.castor.dsml.jndi, com.mysql.jdbc.exceptions.jdbc4, org.exolab.castor.gui, org.castor.persist.cache, org.exolab.castor.xml.util, org.exolab.castor.util, org.exolab.castor.xml.dtd.parser, META-INF, org.exolab.castor.mapping, org.exolab.castor.xml.location, org.castor.cache.hashbelt, org.apache.oro.text, com.mysql.jdbc.exceptions, org.exolab.castor.xml, META-INF.services, org.exolab.castor.jdo, org.castor.cache.hashbelt.container, org.exolab.castor.persist.spi, org.exolab.castor.dtx, org.exolab.castor.xml.schema.simpletypes, org.castor.persist, org.apache.oro.text.awk, org.apache.oro.io, org.castor.cache, com.mysql.jdbc.integration.jboss, org.exolab.castor.xml.schema.simpletypes.factory, org.exolab.castor.xml.handlers, org.castor.jdo.drivers, org.exolab.castor.xml.dtd, com.mysql.jdbc.integration.c3p0, org.exolab.castor.net, org.castor.util, org.castor.cache.hashbelt.reaper, org.exolab.castor.dsml.schema, org.castor.mapping, org.castor.persist.proxy, org.exolab.castor.mapping.xml, com.mysql.jdbc.interceptors, ] <IMPORT-ALL>NON_EMPTY}}
>     at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:381)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>     at java.lang.Class.forName0(Native Method)
>     at java.lang.Class.forName(Class.java:242)
>     at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.getDriver(LocalManagedConnectionFactory.java:474)
> 2008-09-22 11:43:56,718 WARN  [org.jboss.wsf.container.jboss50.deployer.JAXWSDeployerHookPreJSE] (main) Cannot load servlet class: org.apache.struts.action.ActionServlet
> 2008-09-22 11:44:03,031 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Configured: name=jboss.jacc:id="vfszip:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplication-ejb.jar",parent="myapplication.ear",service=jacc state=Instantiated mode=Manual requiredState=Configured
> org.jboss.deployment.DeploymentException: No Attribute found with name: PolicyConfigurationFacadeMBean for jboss.jacc:service=jacc,id="vfszip:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplication-ejb.jar",parent="myapplication.ear", attributes: [JaccContextID, PolicyConfiguration]
>     at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:127)
>     at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:99)
>     at org.jboss.system.microcontainer.ConfigureAction.installAction(ConfigureAction.java:58)
>     at org.jboss.system.microcontainer.ConfigureAction.installAction(ConfigureAction.java:42)
>     at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
>     at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
>     at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
>     at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>     at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Fri Jun 12 08:56:57 2009
From: jira-events at lists.jboss.org (Mathiyalagan Gopal (JIRA))
Date: Fri, 12 Jun 2009 08:56:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7011) Jboss high memory
 leak in SMP
 kernel 2.6.9-78.0.13.ELsmp but not in Non-SMP kernel 2.6.9-78.0.13.EL
Message-ID: <25374810.1244811417061.JavaMail.jira@cloud.prod.atl2.jboss.com>

Jboss high memory leak in SMP kernel 2.6.9-78.0.13.ELsmp but not in Non-SMP kernel 2.6.9-78.0.13.EL
---------------------------------------------------------------------------------------------------

                 Key: JBAS-7011
                 URL: https://jira.jboss.org/jira/browse/JBAS-7011
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.0.5.GA
         Environment: HP DL380 G4 with 4 GB RAM and Duel Core CPU with 3.60 GHz, Linux AS 4 64-bit 2.6.9-78.0.13.ELsmp.
            Reporter: Mathiyalagan Gopal
            Priority: Critical


Hello All,
We are the GE AssetIntelligence running our J2EE based web application in the famous combination of apache + Jboss servers. Our site was running now almost 2 yrs...after deep JVM memory investigation I found there is huge memory leak in the SMP kernel Linux Jboss systems. When I switched the same machine to run on Non-SMP kernel (i,e EL rather then ELsmp) the memory management handeled very well.
When we run our Jboss application server in SMP kernel we have to bounce our jboss instance minimum 2 times a day to reset the JVM Heap, but with non-SMP kernel its running fine and we dont have to do anything. Is anybody out here facing the same issue?

Note : For JVM heap diagnosis we used JProbe as well as Java inbuilt "jmap" utility to generate the report every hour for heap size and live objects.


I am running following versions of servers,

Hardware :HP DL 380 G4 ( 4 GB RAM , 2 Duel Core CPU 3.60 GHz)
Server 1 : Apache-2.2.11
Server 2,3 & 4 : Jboss-4.0.5.GA 

Using apache-2.2.x (mod_loadbalancer) module to connect back end servers.

My JAVA_OPTS vales are

 JAVA_OPTS="-Xms3096m -Xmx3096m -XX:MaxPermSize=256m -Djavax.xml.ws.spi.Provider=org.apache.cxf.jaxws.spi.ProviderImpl -Dorg.apache.cxf.bus.factory=org.apache.cxf.bus.CXFBusFactory -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.partition.name=vip-production-lpap03XXXX -Dtsf.environment=PRD -Dnodename=XXXXXXXX"

Any help will be appreciated!!


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 09:36:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 12 Jun 2009 09:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-71) JBoss TS 4.6.1.GA
In-Reply-To: <3458115.1236869844986.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22684036.1244813816455.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jesper Pedersen updated JBJCA-71:
---------------------------------

    Summary: JBoss TS 4.6.1.GA  (was: JBoss TS 4.4.0.GA)


> JBoss TS 4.6.1.GA
> -----------------
>
>                 Key: JBJCA-71
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-71
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha1
>
>
> Standalone + Test

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 09:42:56 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 12 Jun 2009 09:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMICROCONT-445) Make
 'gettingStarted' example work when run with custom classloader
Message-ID: <19601810.1244814176467.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make 'gettingStarted' example work when run with custom classloader
-------------------------------------------------------------------

                 Key: JBMICROCONT-445
                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-445
             Project: JBoss Microcontainer
          Issue Type: Bug
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: JBossMC-2.2.x


https://svn.jboss.org/repos/jbossas/projects/microcontainer/mcdocs/trunk/examples/User_Guide/gettingStarted
$mvn install
$cd commandLineClient
$mvn install
$cd target/client-cl.dir
$./run.sh bus

The Client class references classes such as Employee which are only present in the humanResourcesService-1.0.0.jar which is loaded by another classloader

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 10:41:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 12 Jun 2009 10:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1653) specify the
 management attribute as lower-cased in management messages
Message-ID: <2107452.1244817716743.JavaMail.jira@cloud.prod.atl2.jboss.com>

specify the management attribute as lower-cased in management messages
----------------------------------------------------------------------

                 Key: JBMESSAGING-1653
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1653
             Project: JBoss Messaging
          Issue Type: Task
          Components: Configuration and Management
    Affects Versions: 2.0.0 Beta1
            Reporter: Jeff Mesnil
            Assignee: Tim Fox
            Priority: Minor
             Fix For: 2.0.0


to be more consistent with Java conventions, the user should be able to specify management attribute lower-cased when sending
management message with ManagementHelper.putAttribute() method.
E.g. to retrieve the value of the QueueContrlol's messageCount, the user will call ManagementHelper.putAttribute(msg, res, "messageCount") and no longer  ManagementHelper.putAttribute(msg, res, "MessageCount")

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 11:08:57 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 12 Jun 2009 11:08:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1643868.1244819337237.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Kabir Khan reassigned JBAS-6888:
--------------------------------

    Assignee: Flavia Rainone  (was: Kabir Khan)


> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Flavia Rainone
>         Attachments: server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 11:12:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 12 Jun 2009 11:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9832692.1244819576433.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer reopened JBAS-7010:
--------------------------------



Scott, I'm using the latest from the EAP branch and am still getting the "Caller unauthorized" error. The client I'm using is at https://svn.jboss.org/repos/jopr/trunk/etc/jbas5-ejb-client/. Would you please try with my client and see if it fails for you as well, and, if so, see if you can figure out what's wrong.


> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 11:27:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 12 Jun 2009 11:27:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1654) Optimization
 on Journal: Use optimized buffers instead of ByteBuffer
In-Reply-To: <8071800.1244820476823.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4025682.1244820477065.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic closed JBMESSAGING-1654.
----------------------------------------

    Resolution: Done


> Optimization on Journal: Use optimized buffers instead of ByteBuffer
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1654
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1654
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Tim Fox
>             Fix For: 2.0.0.beta2
>
>
> Instead of using ByteBuffer on the journal, we are now using MessagingBuffer (HeapBuffer), and that manages a byte array directly, doing faster copies with System.arrayCopy what is much faster than the way ByteBuffer copies them.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 11:27:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 12 Jun 2009 11:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1654) Optimization
 on Journal: Use optimized buffers instead of ByteBuffer
Message-ID: <8071800.1244820476823.JavaMail.jira@cloud.prod.atl2.jboss.com>

Optimization on Journal: Use optimized buffers instead of ByteBuffer
--------------------------------------------------------------------

                 Key: JBMESSAGING-1654
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1654
             Project: JBoss Messaging
          Issue Type: Feature Request
            Reporter: Clebert Suconic
            Assignee: Tim Fox
             Fix For: 2.0.0.beta2


Instead of using ByteBuffer on the journal, we are now using MessagingBuffer (HeapBuffer), and that manages a byte array directly, doing faster copies with System.arrayCopy what is much faster than the way ByteBuffer copies them.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 11:48:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 12 Jun 2009 11:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-84) Add support for
 hasAnnotation(Class) and getAnnotation(Class)
Message-ID: <11699216.1244821736498.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for hasAnnotation(Class) and getAnnotation(Class)
-------------------------------------------------------------

                 Key: JASSIST-84
                 URL: https://jira.jboss.org/jira/browse/JASSIST-84
             Project: Javassist
          Issue Type: Feature Request
            Reporter: Jesper Pedersen
            Assignee: Shigeru Chiba


It would nice if Javassist had functionality to query 

 boolean hasAnnotation(Class)

and retrieve a single annotation 

 Object getAnnotation(Class)

for CtClass, CtBehavior and CtField.

The attached implements this functionality against CVS HEAD.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 11:50:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 12 Jun 2009 11:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-84) Add support for
 hasAnnotation(Class) and getAnnotation(Class)
In-Reply-To: <11699216.1244821736498.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14181594.1244821856950.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jesper Pedersen updated JASSIST-84:
-----------------------------------

    Attachment: JASSIST-84.patch


> Add support for hasAnnotation(Class) and getAnnotation(Class)
> -------------------------------------------------------------
>
>                 Key: JASSIST-84
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-84
>             Project: Javassist
>          Issue Type: Feature Request
>            Reporter: Jesper Pedersen
>            Assignee: Shigeru Chiba
>         Attachments: JASSIST-84.patch
>
>
> It would nice if Javassist had functionality to query 
>  boolean hasAnnotation(Class)
> and retrieve a single annotation 
>  Object getAnnotation(Class)
> for CtClass, CtBehavior and CtField.
> The attached implements this functionality against CVS HEAD.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:14:57 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 12 Jun 2009 06:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1650) The standalone
 clustered config uses property substitution in the beans file
In-Reply-To: <23696594.1244801696672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24734032.1244801697115.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andy Taylor closed JBMESSAGING-1650.
------------------------------------

    Resolution: Done


fixed

> The standalone clustered config uses property substitution in the beans file
> ----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1650
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1650
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>             Fix For: 2.0.0.beta2
>
>
> The standalone clustered config uses property substitution in the beans file but supplies no defaults. This means that starting the server always falls over

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:14:56 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 12 Jun 2009 06:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1650) The
 standalone clustered
 config uses property substitution in the beans file
Message-ID: <23696594.1244801696672.JavaMail.jira@cloud.prod.atl2.jboss.com>

The standalone clustered config uses property substitution in the beans file
----------------------------------------------------------------------------

                 Key: JBMESSAGING-1650
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1650
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0 Beta1
            Reporter: Andy Taylor
            Assignee: Tim Fox
             Fix For: 2.0.0.beta2


The standalone clustered config uses property substitution in the beans file but supplies no defaults. This means that starting the server always falls over

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 12:10:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Fri, 12 Jun 2009 12:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Work started: (JBID-71) Automatic
 installation of IDM Component for Hudson Runs
In-Reply-To: <22073830.1237893802542.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8564238.1244823056725.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Work on JBID-71 started by Jeff Yu.

> Automatic installation of IDM Component for Hudson Runs
> -------------------------------------------------------
>
>                 Key: JBID-71
>                 URL: https://jira.jboss.org/jira/browse/JBID-71
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>    Affects Versions: IDFED-1.0.0.CR1
>            Reporter: Tom Baeyens
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> In jBPM, as part of our hudson runs, we'll need an automatic install of the idm component in JBoss.   The script should take as input the database and a number of jdbc properties.
> Also the DataSource creation should be part of the automatic install.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 12:10:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Fri, 12 Jun 2009 12:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-71) Automatic
 installation of IDM Component for Hudson Runs
In-Reply-To: <22073830.1237893802542.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7226729.1244823056974.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Yu resolved JBID-71.
-------------------------

    Fix Version/s: idm-1.0.0.Beta1
                       (was: idm-1.0.0.GA)
       Resolution: Done


> Automatic installation of IDM Component for Hudson Runs
> -------------------------------------------------------
>
>                 Key: JBID-71
>                 URL: https://jira.jboss.org/jira/browse/JBID-71
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>    Affects Versions: IDFED-1.0.0.CR1
>            Reporter: Tom Baeyens
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> In jBPM, as part of our hudson runs, we'll need an automatic install of the idm component in JBoss.   The script should take as input the database and a number of jdbc properties.
> Also the DataSource creation should be part of the automatic install.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 12:26:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 12 Jun 2009 12:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7012) exclude the
 admin-console from annotation scanning
In-Reply-To: <25457167.1244823656534.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8414446.1244824016598.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Emanuel Muckenhuber resolved JBAS-7012.
---------------------------------------

    Resolution: Done


> exclude the admin-console from annotation scanning
> --------------------------------------------------
>
>                 Key: JBAS-7012
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7012
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 12:40:59 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 12 Jun 2009 12:40:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17105437.1244824859133.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1456:
-----------------------------------------

Hi Victor,

the jars in the zip may not contain some other fixes in 1.4.4. But regarding to this fix, they should be the same. I wouldn't suggest you drop them to your production env. If you have a test env, you can try it. 

Or if you can tell me how to reproduce, I'll try myself.

Thanks,
Howard


> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 12:13:03 2009
From: jira-events at lists.jboss.org (Victor Starenky (JIRA))
Date: Fri, 12 Jun 2009 12:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4023589.1244823183072.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Victor Starenky commented on JBMESSAGING-1456:
----------------------------------------------

But the one we're currently using is 1.4.4
Would it be a safe drop-in replacement?

> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 12:20:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 12 Jun 2009 12:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7012) exclude the
 admin-console from annotation scanning
Message-ID: <25457167.1244823656534.JavaMail.jira@cloud.prod.atl2.jboss.com>

exclude the admin-console from annotation scanning
--------------------------------------------------

                 Key: JBAS-7012
                 URL: https://jira.jboss.org/jira/browse/JBAS-7012
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 13:04:58 2009
From: jira-events at lists.jboss.org (Victor Starenky (JIRA))
Date: Fri, 12 Jun 2009 13:04:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27075283.1244826298433.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Victor Starenky commented on JBMESSAGING-1456:
----------------------------------------------

well, it's a production environment that is able to reproduce this specific bug more or less reliably. so we'll see if we can put these jars in prod to get some useful logs for both this issue as well as JBMESSAGING-1631 

> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 13:12:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 13:12:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20605984.1244826777312.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox closed JBMESSAGING-1646.
--------------------------------

    Resolution: Done


> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>         Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>             Fix For: 2.0.0.beta2
>
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 13:12:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 13:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1655) Default
 clustered config is incorrect
Message-ID: <24332670.1244826776782.JavaMail.jira@cloud.prod.atl2.jboss.com>

Default clustered config is incorrect
-------------------------------------

                 Key: JBMESSAGING-1655
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1655
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
            Assignee: Tim Fox
             Fix For: 2.0.0.beta2


Default clustered configs are incorrect - need adjusting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 13:12:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 13:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1655) Default
 clustered config is incorrect
In-Reply-To: <24332670.1244826776782.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1890857.1244826776960.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox closed JBMESSAGING-1655.
--------------------------------

    Resolution: Done


> Default clustered config is incorrect
> -------------------------------------
>
>                 Key: JBMESSAGING-1655
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1655
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0.beta2
>
>
> Default clustered configs are incorrect - need adjusting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 14:19:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 12 Jun 2009 14:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1849) Update
 dependency chain for Plugin 1.0.9 Release
In-Reply-To: <17075972.1244796188455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30680112.1244830796655.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai resolved EJBTHREE-1849.
------------------------------------

    Resolution: Done


Plugin 1.0.9 has been released

> Update dependency chain for Plugin 1.0.9 Release
> ------------------------------------------------
>
>                 Key: EJBTHREE-1849
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1849
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: plugin
>            Reporter: Andrew Lee Rubinger
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> Container task to track commits to update the dependency chain for the EJB3 Plugin 1.0.9 release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 14:22:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 14:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1839) Implement
 POJO-based, @ManagedObject Session Metrics
In-Reply-To: <32587729.1243384676916.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5895754.1244830976584.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger updated EJBTHREE-1839:
------------------------------------------

    Fix Version/s: 1.1.8
                       (was: 1.1.7)


> Implement POJO-based, @ManagedObject Session Metrics
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1839
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1839
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: metrics-deployer
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.8
>
>         Attachments: metrics.patch
>
>
> Defined by JBAS-6624.
> Consoles need Statistics accessible via ProfileService and jboss-management @ManagedObjects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 14:22:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 14:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1831) Clean up
	dependency chains
In-Reply-To: <13433231.1242136368008.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10267537.1244830976810.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger updated EJBTHREE-1831:
------------------------------------------

    Fix Version/s: 1.1.8
                       (was: 1.1.7)


> Clean up dependency chains
> --------------------------
>
>                 Key: EJBTHREE-1831
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1831
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: as-int, ejb3
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.8
>
>
> The true order should be:
> jboss-ejb3 > as-int > AS
> jboss-ejb3 > Plugin
> Whereas now as-int goes into Plugin.  Also endpoint-deployer should be included in as-int and Plugin, and not explicitly declared by AS itself.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 14:22:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 14:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1814)
 NoPassivationCache does not obey maxSize
In-Reply-To: <17499438.1240909569920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23256624.1244830976956.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger updated EJBTHREE-1814:
------------------------------------------

    Fix Version/s: 1.1.8
                       (was: 1.1.7)


> NoPassivationCache does not obey maxSize
> ----------------------------------------
>
>                 Key: EJBTHREE-1814
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1814
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: cache
>            Reporter: Carlo de Wolf
>             Fix For: 1.1.8
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 14:28:57 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Fri, 12 Jun 2009 14:28:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7013) Seam Booking
 IOException with JSF2 Beta1 on AS5
Message-ID: <23174748.1244831337615.JavaMail.jira@cloud.prod.atl2.jboss.com>

Seam Booking IOException with JSF2 Beta1 on AS5
-----------------------------------------------

                 Key: JBAS-7013
                 URL: https://jira.jboss.org/jira/browse/JBAS-7013
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Stan Silvert
            Assignee: Stan Silvert


I drop-in replaced JSF in AS5.1 with JSF 2 Beta 1.  

With the Seam Booking demo, I bundle the old facelets and have:
   <context-param>
      <param-name>javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER</param-name>
      <param-value>true</param-value>
    </context-param>

I get the stack trace below.  Though it doesn't seem to affect the application, I need to figure out why this is happening.

13:38:34,463 ERROR [compiler] Error Loading Library: vfszip:/C:/jboss-5.1.0.GA/s
erver/default/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.tag
lib.xml
java.io.IOException: Error parsing [vfszip:/C:/jboss-5.1.0.GA/server/default/dep
loy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.taglib.xml]:
        at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.ja
va:410)
        at com.sun.facelets.compiler.TagLibraryConfig.loadImplicit(TagLibraryCon
fig.java:431)
        at com.sun.facelets.compiler.Compiler.initialize(Compiler.java:87)
        at com.sun.facelets.compiler.Compiler.compile(Compiler.java:104)
        at com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFace
letFactory.java:218)
        at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFacelet
Factory.java:149)
        at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFacelet
Factory.java:100)
        at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java
:517)
        at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.jav
a:567)
        at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWra
pper.java:108)
        at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.j
ava:216)
        at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePha
se.java:124)
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:103)
        at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:311)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:83)
        at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:69)
        at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:69)
        at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:69)
        at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:69)
        at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)

        at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
        at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:69)
        at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:69)
        at org.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:69)
        at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFi
lter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:235)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:191)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(Securit
yAssociationValve.java:190)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValv
e.java:92)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.proce
ss(SecurityContextEstablishmentValve.java:126)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invok
e(SecurityContextEstablishmentValve.java:70)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:102)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedC
onnectionValve.java:158)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:330)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:829)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
ss(Http11Protocol.java:598)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44
7)
        at java.lang.Thread.run(Thread.java:619)
Caused by: org.xml.sax.SAXException: Error Handling [vfszip:/C:/jboss-5.1.0.GA/s
erver/default/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.tag
lib.xml at 42,29]
        at com.sun.facelets.compiler.TagLibraryConfig$LibraryHandler.error(TagLi
braryConfig.java:376)
        at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
        at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
        at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
        at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
        at org.apache.xerces.impl.dtd.XMLDTDValidator.rootElementSpecified(Unkno
wn Source)
        at org.apache.xerces.impl.dtd.XMLDTDValidator.handleStartElement(Unknown
 Source)
        at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Sourc
e)
        at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElemen
t(Unknown Source)
        at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanR
ootElementHook(Unknown Source)
        at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
Dispatcher.dispatch(Unknown Source)
        at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un
known Source)
        at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
        at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
        at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
        at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
        at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Sour
ce)
        at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
        at javax.xml.parsers.SAXParser.parse(SAXParser.java:198)
        at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.ja
va:407)
        ... 54 more
Caused by: org.xml.sax.SAXParseException: Document root element "facelet-taglib"
, must match DOCTYPE root "null".
        at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Un
known Source)
        ... 73 more


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 15:08:56 2009
From: jira-events at lists.jboss.org (Duane Olawsky (JIRA))
Date: Fri, 12 Jun 2009 15:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-990) Grammatical Error in
 log message: I'm being am suspected.
Message-ID: <15502315.1244833736783.JavaMail.jira@cloud.prod.atl2.jboss.com>

Grammatical Error in log message: I'm being am suspected.
---------------------------------------------------------

                 Key: JGRP-990
                 URL: https://jira.jboss.org/jira/browse/JGRP-990
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.4.1
         Environment: N/A
            Reporter: Duane Olawsky
            Assignee: Bela Ban
            Priority: Trivial


There is a grammatical error in the following log message:

"WARN - I am the coord and I'm being am suspected -- will probably leave shortly"

I suggest removing the second "am".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 15:49:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 12 Jun 2009 15:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7014) JChannelFactory
 addSingletonName handling broken
Message-ID: <26543394.1244836196419.JavaMail.jira@cloud.prod.atl2.jboss.com>

JChannelFactory addSingletonName handling broken
------------------------------------------------

                 Key: JBAS-7014
                 URL: https://jira.jboss.org/jira/browse/JBAS-7014
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.1.0.CR1
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-5.2.0.Beta1


The expected path for the AS JChannelFactory's addSingletonName logic is broken -- it thinks it is mutating the passed in config but it isn't.

Luckily this is minor because there's separate logic that executes when JGroups throws an UnsupportedOperationException -- said logic works correctly and JGroups always throws the exception. But if a later release of JGroups fixed the UOE, this bug would be exposed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 15:59:56 2009
From: jira-events at lists.jboss.org (Gavin King (JIRA))
Date: Fri, 12 Jun 2009 15:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1245515.1244836796622.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Gavin King reopened EJBTHREE-995:
---------------------------------



What?! This is a major bug that is easy to reproduce. No I'm not going to write the tests. This affects Seam and anyone who uses SessionSynchronization.

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 16:09:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 12 Jun 2009 16:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7015) AS JChannelFactory
 should always add singleton_name
Message-ID: <10577550.1244837396926.JavaMail.jira@cloud.prod.atl2.jboss.com>

AS JChannelFactory should always add singleton_name
---------------------------------------------------

                 Key: JBAS-7015
                 URL: https://jira.jboss.org/jira/browse/JBAS-7015
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-6.0.0.Alpha1


Currently it only adds a singleton_name if channel is requested via createMultiplexerChannel() methods, not for createChannel(String stack). But the latter will possibly become the default, and if two services request channels from the same stack and there is no singleton_name, there will be conflicts. The AS should use a shared transport whenever possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 17:05:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 12 Jun 2009 17:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7015) AS JChannelFactory
 should always add singleton_name
In-Reply-To: <10577550.1244837396926.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6571304.1244840756501.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry commented on JBAS-7015:
----------------------------------------

Qualifying the title: it should always add singleton_name if the API methods that provide a stack_name are used. It won't create a singleton_name if createChannel(Object properties) is invoked as in that case there is no stack_name to serve as an indicator that the given config has been used before.

> AS JChannelFactory should always add singleton_name
> ---------------------------------------------------
>
>                 Key: JBAS-7015
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7015
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Currently it only adds a singleton_name if channel is requested via createMultiplexerChannel() methods, not for createChannel(String stack). But the latter will possibly become the default, and if two services request channels from the same stack and there is no singleton_name, there will be conflicts. The AS should use a shared transport whenever possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 17:07:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 12 Jun 2009 17:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7016) Management interface
 for JChannelFactory
Message-ID: <9111063.1244840876545.JavaMail.jira@cloud.prod.atl2.jboss.com>

Management interface for JChannelFactory
----------------------------------------

                 Key: JBAS-7016
                 URL: https://jira.jboss.org/jira/browse/JBAS-7016
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 17:24:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 17:24:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2576296.1244841897115.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger updated EJBTHREE-995:
-----------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237390


> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 17:24:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 17:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11531522.1244841896711.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471981#action_12471981 ] 

Andrew Lee Rubinger commented on EJBTHREE-995:
----------------------------------------------

Collaboration is more effective than persistent complaints.

For starters, please check the test I've added to ensure that it covers the issue you describe.  I've opened a forum Thread for discussion.

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 17:56:56 2009
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Fri, 12 Jun 2009 17:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16770319.1244843816556.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Remy Maucherat commented on JBWEB-144:
--------------------------------------

So I suppose your plan is to merge this patch chain in the CP branch ?

> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 20:19:57 2009
From: jira-events at lists.jboss.org (Daniel munford (JIRA))
Date: Fri, 12 Jun 2009 20:19:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6590) AS5 is not
 reliably picking up changes in exploded EAR
In-Reply-To: <5022560.1236474262651.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28970234.1244852397592.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Daniel munford commented on JBAS-6590:
--------------------------------------

I have confirmed that this is still happening in JBoss AS 5.1.0 GA release.  Is there an ETA on when the bug will be fixed?

> AS5 is not reliably picking up changes in exploded EAR
> ------------------------------------------------------
>
>                 Key: JBAS-6590
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6590
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: JBoss AS 5.0.1.GA
> JDK 1.5
> Mac OS X 10.5.6
>            Reporter: Kenneth Christensen
>            Assignee: Ales Justin
>            Priority: Critical
>         Attachments: ear.jpg, jboss5-test.ear.zip, tmp-ear.jpg
>
>
> I have an explode ear file (directory) - see attached file: ear.jpg
> When I deploy the exploded ear file to JBoss AS 4.2.3 and later want to update a xhtml file in the exploded ear by my ANT script everything works fine (i.e. I can refresh my browser and see the changes without redeployment of the ear or war):
>     <!-- Target: deploy.xhtml.to.jboss -->
>     <target name="deploy.xhtml.to.jboss" description="Deploy xhtml files to JBoss" if="deployed">
>         <copy todir="${jboss.deploy.dir}/${jboss.context.path}/${war.file.name}/xhtml">
>             <fileset dir="${view.dir}/xhtml" includes="**/*"/>
>         </copy>
>     </target>
> Because the exploded ear file is not copied to JBoss tmp dir.
> But JBoss AS 5 always makes a copy of my exploded ear file and copies it to the tmp dir where it's the current 'working copy/version' used by JBoss AS - see attached file: tmp-ear.jpg
> My ANT task will not work anymore because the 'working copy/version' used by JBoss AS now is in the tmp dir and not in the deploy dir.
> I really don't want to 'touch' web.xml (or other meta files) to trigger a full redeployment when I need to make changes to my web files (xhtml, css, javascript, images etc.).
> Could we please have the 'old' behaviour from JBoss AS 4.2.X implemented into JBoss AS 5 - or is there a workaround to above problem?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 13 02:14:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 13 Jun 2009 02:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-990) Grammatical Error in
 log message: I'm being am suspected.
In-Reply-To: <15502315.1244833736783.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30995966.1244873697135.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban updated JGRP-990:
--------------------------

    Fix Version/s: 2.4.7


> Grammatical Error in log message: I'm being am suspected.
> ---------------------------------------------------------
>
>                 Key: JGRP-990
>                 URL: https://jira.jboss.org/jira/browse/JGRP-990
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.1
>         Environment: N/A
>            Reporter: Duane Olawsky
>            Assignee: Bela Ban
>            Priority: Trivial
>             Fix For: 2.4.7
>
>
> There is a grammatical error in the following log message:
> "WARN - I am the coord and I'm being am suspected -- will probably leave shortly"
> I suggest removing the second "am".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 13 07:21:57 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Sat, 13 Jun 2009 07:21:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6590) AS5 is not
 reliably picking up changes in exploded EAR
In-Reply-To: <5022560.1236474262651.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19720572.1244892117745.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin commented on JBAS-6590:
-----------------------------------

>> I have confirmed that this is still happening in JBoss AS 5.1.0 GA release. Is there an ETA on when the bug will be fixed? 

Yes, this was already filed under JBDEPLOY-192.
It will be resolved with a new Deployers release.

> AS5 is not reliably picking up changes in exploded EAR
> ------------------------------------------------------
>
>                 Key: JBAS-6590
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6590
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: JBoss AS 5.0.1.GA
> JDK 1.5
> Mac OS X 10.5.6
>            Reporter: Kenneth Christensen
>            Assignee: Ales Justin
>            Priority: Critical
>         Attachments: ear.jpg, jboss5-test.ear.zip, tmp-ear.jpg
>
>
> I have an explode ear file (directory) - see attached file: ear.jpg
> When I deploy the exploded ear file to JBoss AS 4.2.3 and later want to update a xhtml file in the exploded ear by my ANT script everything works fine (i.e. I can refresh my browser and see the changes without redeployment of the ear or war):
>     <!-- Target: deploy.xhtml.to.jboss -->
>     <target name="deploy.xhtml.to.jboss" description="Deploy xhtml files to JBoss" if="deployed">
>         <copy todir="${jboss.deploy.dir}/${jboss.context.path}/${war.file.name}/xhtml">
>             <fileset dir="${view.dir}/xhtml" includes="**/*"/>
>         </copy>
>     </target>
> Because the exploded ear file is not copied to JBoss tmp dir.
> But JBoss AS 5 always makes a copy of my exploded ear file and copies it to the tmp dir where it's the current 'working copy/version' used by JBoss AS - see attached file: tmp-ear.jpg
> My ANT task will not work anymore because the 'working copy/version' used by JBoss AS now is in the tmp dir and not in the deploy dir.
> I really don't want to 'touch' web.xml (or other meta files) to trigger a full redeployment when I need to make changes to my web files (xhtml, css, javascript, images etc.).
> Could we please have the 'old' behaviour from JBoss AS 4.2.X implemented into JBoss AS 5 - or is there a workaround to above problem?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 14 11:36:04 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Sun, 14 Jun 2009 11:36:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14663923.1244993764331.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1456:
-----------------------------------------

Thanks Victor. Please note that:

1. If you have long live sessions, it is possible the messages got 'stuck' until the session is closed.
2. if session is not closed while failover is happening, the following parameter affects how long the messages will be canceled back to queue for redelivery:

<attribute name="clientLeasePeriod" isParam="true">30000</attribute> 

For the above value, the 'stuck' message will not be canceled back until at least 30 sec after the client has finished failover.



> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 14 17:09:57 2009
From: jira-events at lists.jboss.org (Przemyslaw Rozycki (JIRA))
Date: Sun, 14 Jun 2009 17:09:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1946) Deserializing a
 KnowledgeBase object throws a java.io.EOFException
In-Reply-To: <13586666.1233155564971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16770076.1245013797192.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Przemyslaw Rozycki commented on JBRULES-1946:
---------------------------------------------

Unfortunately, I use 5.0.1 and still have this problem. I will attach my example which is a bit simpler. Please, reopen the case (I can't).

> Deserializing a KnowledgeBase object throws a java.io.EOFException
> ------------------------------------------------------------------
>
>                 Key: JBRULES-1946
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1946
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions:  5.0.0.M4, 5.0.0.M5
>         Environment: Ubuntu 8.10
>            Reporter: Simon Kelly
>            Assignee: Edson Tirelli
>             Fix For: 5.0.1.FINAL
>
>         Attachments: drools.test.zip, DroolsTest.java, Sample.drl
>
>
> A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file.
> java.io.EOFException
> 	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
> 	at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
> 	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
> 	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49)
> 	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227)
> 	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173)
> 	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at com.sample.DroolsTest.read(DroolsTest.java:75)
> 	at com.sample.DroolsTest.testIO(DroolsTest.java:50)
> 	at com.sample.DroolsTest.main(DroolsTest.java:40)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 14 17:23:56 2009
From: jira-events at lists.jboss.org (Przemyslaw Rozycki (JIRA))
Date: Sun, 14 Jun 2009 17:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1946) Deserializing a
 KnowledgeBase object throws a java.io.EOFException
In-Reply-To: <13586666.1233155564971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21415106.1245014636767.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Przemyslaw Rozycki updated JBRULES-1946:
----------------------------------------

    Attachment: Sandbox2.java


A Java test code.

> Deserializing a KnowledgeBase object throws a java.io.EOFException
> ------------------------------------------------------------------
>
>                 Key: JBRULES-1946
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1946
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions:  5.0.0.M4, 5.0.0.M5
>         Environment: Ubuntu 8.10
>            Reporter: Simon Kelly
>            Assignee: Edson Tirelli
>             Fix For: 5.0.1.FINAL
>
>         Attachments: drools.test.zip, DroolsTest.java, Sample.drl, Sandbox2.java
>
>
> A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file.
> java.io.EOFException
> 	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
> 	at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
> 	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
> 	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49)
> 	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227)
> 	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173)
> 	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at com.sample.DroolsTest.read(DroolsTest.java:75)
> 	at com.sample.DroolsTest.testIO(DroolsTest.java:50)
> 	at com.sample.DroolsTest.main(DroolsTest.java:40)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 14 17:25:56 2009
From: jira-events at lists.jboss.org (Przemyslaw Rozycki (JIRA))
Date: Sun, 14 Jun 2009 17:25:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1946) Deserializing a
 KnowledgeBase object throws a java.io.EOFException
In-Reply-To: <13586666.1233155564971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28531165.1245014756541.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Przemyslaw Rozycki updated JBRULES-1946:
----------------------------------------

    Attachment: Sample1.drl


Test rules. In fact, it doesn't really matter what rules I use.

> Deserializing a KnowledgeBase object throws a java.io.EOFException
> ------------------------------------------------------------------
>
>                 Key: JBRULES-1946
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1946
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions:  5.0.0.M4, 5.0.0.M5
>         Environment: Ubuntu 8.10
>            Reporter: Simon Kelly
>            Assignee: Edson Tirelli
>             Fix For: 5.0.1.FINAL
>
>         Attachments: drools.test.zip, DroolsTest.java, Sample.drl, Sample1.drl, Sandbox2.java
>
>
> A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file.
> java.io.EOFException
> 	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
> 	at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
> 	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
> 	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49)
> 	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227)
> 	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173)
> 	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at com.sample.DroolsTest.read(DroolsTest.java:75)
> 	at com.sample.DroolsTest.testIO(DroolsTest.java:50)
> 	at com.sample.DroolsTest.main(DroolsTest.java:40)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 02:45:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 15 Jun 2009 02:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1644) Work out a
 suitable way to provide JBM examples/doc for AS 5
In-Reply-To: <25933843.1244563136418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26541853.1245048356528.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1644:
-----------------------------------------

Currently the standard download of AS 5 doesn't include the docs/examples of JBoss Messaging. That makes it hard for new users to learn how to configure and use JBoss Messaging that comes with AS 5 distribution. A lot of questions that the users put to the forum wouldn't have been necessary had there been an easy way to let users get the examples and documents.

However the current structure of a AS 5 distribution structure is not so ready to adapt those doc/example stuff, so I'm trying to find a way to fit in those bits.

My idea is to provide an extra distribution for AS 5. It is a single zip file downloadable along side with the JBoss AS 5 kit on the download page. The name is to be like:

jboss-5.1.0.GA-extra.zip

Once unzipped, it should have the following structure:

jboss-5.1.0.GA/
                       |
                       |----- extra/
                                      |----readme.txt (table of contents)
                                      |
                                      |----jboss-messaging
                                      |                             |
                                      |                             |-----doc
                                      |                             |
                                      |                             |------examples
                                      |
                                      |----other stuffs

This is let the whole stuff be easily copied to an existing AS 5 installation, resulting in an additional /extra sub dir under $JBOSS_HOME.

I believe this method not only address the issue of JBoss Messaging examples/doc, but also can provide a place for some other pieces that are not runtime essential to AS 5. For example, some of the stuff under the docs/ dir is not necessary for a server to startup and many of the files are not related to documentation. Such stuff like that can also goes to the extra package and that will make the AS 5 distribution more concise and slim.

That can benefits both advanced users and novices. For advanced users they don't need to download stuff they don't need. For novices they can easily find more resources regarding to all the supporting components (messaging, transactions, security etc) and get on quickly. That also save many core developers from answering obvious questions. Also this way the users can get the right versions with each release of AS 5 without having to finding out versions of those components within.

To do this, it needs to:

1. Put the extra stuff to somewhere under AS5's maven repository.
2. Add a build target 'extra' to  generate the extra package.
3. Upload the extra zip to the dowload page for AS5.


> Work out a suitable way to provide JBM examples/doc for AS 5
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1644
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1644
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.5.GA
>
>
> Current AS 5 distribution kit doesn't have JBM doc/examples of the corresponding version included, that makes it very inconvenient to use JBM with AS5. Users often get confused with which version of JBM is the correct version, and where to get the resouces (docs, examples).
> We have to provide a solution to that. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 03:40:57 2009
From: jira-events at lists.jboss.org (Ivelin Velkov (JIRA))
Date: Mon, 15 Jun 2009 03:40:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <382983.1245051657118.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ivelin Velkov commented on JBAS-6888:
-------------------------------------

Hi, we are going in production very soon. QA testing for about a month didn't find an issue with the above workaround.

> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Flavia Rainone
>         Attachments: server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 04:24:03 2009
From: jira-events at lists.jboss.org (Vicky Kak (JIRA))
Date: Mon, 15 Jun 2009 04:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1429) Reauthentication
	Support
Message-ID: <10646240.1245054243425.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Vicky Kak updated JBAS-1429:
----------------------------

    Attachment: JBAS-1429


> Reauthentication Support
> ------------------------
>
>                 Key: JBAS-1429
>                 URL: https://jira.jboss.org/jira/browse/JBAS-1429
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Andrew Oliver
>            Assignee: Vicky Kak
>         Attachments: JBAS-1429
>
>
> Add support for the reauthentication support (in particular MySQLChangeUser)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 04:26:56 2009
From: jira-events at lists.jboss.org (Vicky Kak (JIRA))
Date: Mon, 15 Jun 2009 04:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1429) Reauthentication
	Support
Message-ID: <14458392.1245054416791.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Vicky Kak updated JBAS-1429:
----------------------------

    Attachment: ReauthenticationMechansim.java


> Reauthentication Support
> ------------------------
>
>                 Key: JBAS-1429
>                 URL: https://jira.jboss.org/jira/browse/JBAS-1429
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Andrew Oliver
>            Assignee: Vicky Kak
>         Attachments: JBAS-1429, ReauthenticationMechansim.java
>
>
> Add support for the reauthentication support (in particular MySQLChangeUser)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 04:28:56 2009
From: jira-events at lists.jboss.org (Vicky Kak (JIRA))
Date: Mon, 15 Jun 2009 04:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1429) Reauthentication
	Support
Message-ID: <29449832.1245054536954.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Vicky Kak updated JBAS-1429:
----------------------------

    Attachment: MySqlReauthenticationMechansimImpl.java


> Reauthentication Support
> ------------------------
>
>                 Key: JBAS-1429
>                 URL: https://jira.jboss.org/jira/browse/JBAS-1429
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Andrew Oliver
>            Assignee: Vicky Kak
>         Attachments: JBAS-1429, MySqlReauthenticationMechansimImpl.java, ReauthenticationMechansim.java
>
>
> Add support for the reauthentication support (in particular MySQLChangeUser)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 04:31:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 15 Jun 2009 04:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7017) Upgrade EJB3 to 1.1.7
Message-ID: <8087911.1245054716478.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade EJB3 to 1.1.7
---------------------

                 Key: JBAS-7017
                 URL: https://jira.jboss.org/jira/browse/JBAS-7017
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
          Components: EJB3
            Reporter: jaikiran pai
            Assignee: jaikiran pai
             Fix For: JBossAS-5.2.0.Beta1


EJB3 1.1.7 version has been released. Update the AS to use this new version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 04:33:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 15 Jun 2009 04:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7018) Upgrade EJB3 to 1.1.7
Message-ID: <25050850.1245054836512.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade EJB3 to 1.1.7
---------------------

                 Key: JBAS-7018
                 URL: https://jira.jboss.org/jira/browse/JBAS-7018
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
          Components: EJB3
            Reporter: jaikiran pai
            Assignee: jaikiran pai
             Fix For: JBossAS-6.0.0.Alpha1


Update the AS to use the newly released EJB3 1.1.7 version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 04:35:56 2009
From: jira-events at lists.jboss.org (Vicky Kak (JIRA))
Date: Mon, 15 Jun 2009 04:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1429) Reauthentication
	Support
Message-ID: <29368601.1245054956870.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Vicky Kak commented on JBAS-1429:
---------------------------------

Few things to be considered here are 

1) The MySqlReauthenticationMechanism will not work unless changeUser(..) method is added to com.mysql.jdbc.jdbc2.optional.ConnectionWrapper class,
************************************************************************* 
public void changeUser(String userName, String newPassword) throws SQLException {
		checkClosed();

		try {
			this.mc.changeUser(userName,newPassword);
		} catch (SQLException sqlException) {
			checkAndFireConnectionError(sqlException);
		}
	}
************************************************************************* 
2) The unit tests for this change needs to be incorporated.


> Reauthentication Support
> ------------------------
>
>                 Key: JBAS-1429
>                 URL: https://jira.jboss.org/jira/browse/JBAS-1429
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Andrew Oliver
>            Assignee: Vicky Kak
>         Attachments: JBAS-1429, MySqlReauthenticationMechansimImpl.java, ReauthenticationMechansim.java
>
>
> Add support for the reauthentication support (in particular MySQLChangeUser)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 05:04:57 2009
From: jira-events at lists.jboss.org (Przemyslaw Rozycki (JIRA))
Date: Mon, 15 Jun 2009 05:04:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1946) Deserializing a
 KnowledgeBase object throws a java.io.EOFException
In-Reply-To: <13586666.1233155564971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22447036.1245056697696.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Przemyslaw Rozycki commented on JBRULES-1946:
---------------------------------------------

I also tried on the code from trunk (revision 26960) and the problem occurs. All the more I ask for reopening the bug.


> Deserializing a KnowledgeBase object throws a java.io.EOFException
> ------------------------------------------------------------------
>
>                 Key: JBRULES-1946
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1946
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions:  5.0.0.M4, 5.0.0.M5
>         Environment: Ubuntu 8.10
>            Reporter: Simon Kelly
>            Assignee: Edson Tirelli
>             Fix For: 5.0.1.FINAL
>
>         Attachments: drools.test.zip, DroolsTest.java, Sample.drl, Sample1.drl, Sandbox2.java
>
>
> A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file.
> java.io.EOFException
> 	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
> 	at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
> 	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
> 	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49)
> 	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227)
> 	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173)
> 	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at com.sample.DroolsTest.read(DroolsTest.java:75)
> 	at com.sample.DroolsTest.testIO(DroolsTest.java:50)
> 	at com.sample.DroolsTest.main(DroolsTest.java:40)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 06:01:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 15 Jun 2009 06:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1656) Time out
 sessions nearer to connection ttl
Message-ID: <27237646.1245060116436.JavaMail.jira@cloud.prod.atl2.jboss.com>

Time out sessions nearer to connection ttl
------------------------------------------

                 Key: JBMESSAGING-1656
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1656
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
            Assignee: Tim Fox
             Fix For: 2.0.0.beta2


Currently, sessions on the server can be timed out up to 2 * connection TTL ms after a ping has arrived on the server, due to the way pinging and failure checking is done.

We can refactor this somewhat to make sessions timeout much nearer to connection ttl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 06:10:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 15 Jun 2009 06:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7019) Fork the existing
 tomcat integration code from AS into Spider
Message-ID: <22128270.1245060656840.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fork the existing tomcat integration code from AS into Spider
-------------------------------------------------------------

                 Key: JBAS-7019
                 URL: https://jira.jboss.org/jira/browse/JBAS-7019
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 06:10:57 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 15 Jun 2009 06:10:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7020) Remove AS
 dependencies and create SPIs
Message-ID: <25343710.1245060657193.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remove AS dependencies and create SPIs
--------------------------------------

                 Key: JBAS-7020
                 URL: https://jira.jboss.org/jira/browse/JBAS-7020
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 06:12:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 15 Jun 2009 06:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7021) Create a JBoss Spider
 distribution
Message-ID: <9103344.1245060776647.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create a JBoss Spider distribution
----------------------------------

                 Key: JBAS-7021
                 URL: https://jira.jboss.org/jira/browse/JBAS-7021
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Carlo de Wolf




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 06:12:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 15 Jun 2009 06:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7021) Create a JBoss
 Spider distribution
In-Reply-To: <9103344.1245060776647.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12157312.1245060776899.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf reassigned JBAS-7021:
-----------------------------------

    Assignee: Carlo de Wolf


> Create a JBoss Spider distribution
> ----------------------------------
>
>                 Key: JBAS-7021
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7021
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 06:42:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 15 Jun 2009 06:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1656) Time out
 sessions nearer to connection ttl
In-Reply-To: <27237646.1245060116436.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21503170.1245062576815.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox closed JBMESSAGING-1656.
--------------------------------

    Resolution: Done


> Time out sessions nearer to connection ttl
> ------------------------------------------
>
>                 Key: JBMESSAGING-1656
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1656
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0.beta2
>
>
> Currently, sessions on the server can be timed out up to 2 * connection TTL ms after a ping has arrived on the server, due to the way pinging and failure checking is done.
> We can refactor this somewhat to make sessions timeout much nearer to connection ttl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 07:57:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 15 Jun 2009 07:57:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-1946) Deserializing a
 KnowledgeBase object throws a java.io.EOFException
In-Reply-To: <13586666.1233155564971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20190254.1245067077927.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli reopened JBRULES-1946:
------------------------------------



Reopening by user request. Need to check the new test cases.

> Deserializing a KnowledgeBase object throws a java.io.EOFException
> ------------------------------------------------------------------
>
>                 Key: JBRULES-1946
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1946
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions:  5.0.0.M4, 5.0.0.M5
>         Environment: Ubuntu 8.10
>            Reporter: Simon Kelly
>            Assignee: Edson Tirelli
>             Fix For: 5.0.1.FINAL
>
>         Attachments: drools.test.zip, DroolsTest.java, Sample.drl, Sample1.drl, Sandbox2.java
>
>
> A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file.
> java.io.EOFException
> 	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
> 	at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
> 	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
> 	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49)
> 	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227)
> 	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173)
> 	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at com.sample.DroolsTest.read(DroolsTest.java:75)
> 	at com.sample.DroolsTest.testIO(DroolsTest.java:50)
> 	at com.sample.DroolsTest.main(DroolsTest.java:40)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 08:54:07 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Mon, 15 Jun 2009 08:54:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-129)
 java.util.ConcurrentModificationException in HibernateIdentityStoreImpl
 class
Message-ID: <8734936.1245070447420.JavaMail.jira@cloud.prod.atl2.jboss.com>

java.util.ConcurrentModificationException in HibernateIdentityStoreImpl class
-----------------------------------------------------------------------------

                 Key: JBID-129
                 URL: https://jira.jboss.org/jira/browse/JBID-129
             Project: JBoss Identity
          Issue Type: Bug
          Components: IDM
    Affects Versions: idm-1.0.0.Alpha5
            Reporter: Jeff Yu
            Assignee: Jeff Yu
             Fix For: IDFED-1.0.0.beta1



The test case for this error is:

      Group dept = identitySession.getPersistenceManager().createGroup("sales-dept", GROUP);
      User u1 = identitySession.getPersistenceManager().createUser("jeff1");
      User u2 = identitySession.getPersistenceManager().createUser("jeff2");
      RoleType developer = identitySession.getRoleManager().createRoleType("developer");
      identitySession.getRoleManager().createRole(developer, u1, dept);
      identitySession.getRoleManager().createRole(developer, u2, dept);
      
      identitySession.getPersistenceManager().removeGroup(dept, true);
----------------------------------------------------------------------------------------------


Exception stack:
------------------------------------
Caused by: java.util.ConcurrentModificationException
    at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
    at java.util.HashMap$KeyIterator.next(HashMap.java:877)
    at org.hibernate.collection.AbstractPersistentCollection$IteratorProxy.next(AbstractPersistentCollection.java:577)
    at org.jboss.identity.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:500)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 08:55:57 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Mon, 15 Jun 2009 08:55:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-129)
 java.util.ConcurrentModificationException in HibernateIdentityStoreImpl
 class
In-Reply-To: <8734936.1245070447420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6256363.1245070557506.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Yu updated JBID-129:
-------------------------

    Fix Version/s: idm-1.0.0.Beta1
                       (was: IDFED-1.0.0.beta1)


> java.util.ConcurrentModificationException in HibernateIdentityStoreImpl class
> -----------------------------------------------------------------------------
>
>                 Key: JBID-129
>                 URL: https://jira.jboss.org/jira/browse/JBID-129
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: IDM
>    Affects Versions: idm-1.0.0.Alpha5
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> The test case for this error is:
>       Group dept = identitySession.getPersistenceManager().createGroup("sales-dept", GROUP);
>       User u1 = identitySession.getPersistenceManager().createUser("jeff1");
>       User u2 = identitySession.getPersistenceManager().createUser("jeff2");
>       RoleType developer = identitySession.getRoleManager().createRoleType("developer");
>       identitySession.getRoleManager().createRole(developer, u1, dept);
>       identitySession.getRoleManager().createRole(developer, u2, dept);
>       
>       identitySession.getPersistenceManager().removeGroup(dept, true);
> ----------------------------------------------------------------------------------------------
> Exception stack:
> ------------------------------------
> Caused by: java.util.ConcurrentModificationException
>     at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
>     at java.util.HashMap$KeyIterator.next(HashMap.java:877)
>     at org.hibernate.collection.AbstractPersistentCollection$IteratorProxy.next(AbstractPersistentCollection.java:577)
>     at org.jboss.identity.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:500)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 08:55:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Mon, 15 Jun 2009 08:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Work started: (JBID-129)
 java.util.ConcurrentModificationException in HibernateIdentityStoreImpl
 class
In-Reply-To: <8734936.1245070447420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16759279.1245070556683.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Work on JBID-129 started by Jeff Yu.

> java.util.ConcurrentModificationException in HibernateIdentityStoreImpl class
> -----------------------------------------------------------------------------
>
>                 Key: JBID-129
>                 URL: https://jira.jboss.org/jira/browse/JBID-129
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: IDM
>    Affects Versions: idm-1.0.0.Alpha5
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> The test case for this error is:
>       Group dept = identitySession.getPersistenceManager().createGroup("sales-dept", GROUP);
>       User u1 = identitySession.getPersistenceManager().createUser("jeff1");
>       User u2 = identitySession.getPersistenceManager().createUser("jeff2");
>       RoleType developer = identitySession.getRoleManager().createRoleType("developer");
>       identitySession.getRoleManager().createRole(developer, u1, dept);
>       identitySession.getRoleManager().createRole(developer, u2, dept);
>       
>       identitySession.getPersistenceManager().removeGroup(dept, true);
> ----------------------------------------------------------------------------------------------
> Exception stack:
> ------------------------------------
> Caused by: java.util.ConcurrentModificationException
>     at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
>     at java.util.HashMap$KeyIterator.next(HashMap.java:877)
>     at org.hibernate.collection.AbstractPersistentCollection$IteratorProxy.next(AbstractPersistentCollection.java:577)
>     at org.jboss.identity.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:500)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 09:01:57 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 15 Jun 2009 09:01:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBID-129)
 java.util.ConcurrentModificationException in HibernateIdentityStoreImpl
 class
In-Reply-To: <8734936.1245070447420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4893155.1245070917102.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBID-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472076#action_12472076 ] 

Anil Saldhana commented on JBID-129:
------------------------------------

ConcurrentHashMap?

> java.util.ConcurrentModificationException in HibernateIdentityStoreImpl class
> -----------------------------------------------------------------------------
>
>                 Key: JBID-129
>                 URL: https://jira.jboss.org/jira/browse/JBID-129
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: IDM
>    Affects Versions: idm-1.0.0.Alpha5
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> The test case for this error is:
>       Group dept = identitySession.getPersistenceManager().createGroup("sales-dept", GROUP);
>       User u1 = identitySession.getPersistenceManager().createUser("jeff1");
>       User u2 = identitySession.getPersistenceManager().createUser("jeff2");
>       RoleType developer = identitySession.getRoleManager().createRoleType("developer");
>       identitySession.getRoleManager().createRole(developer, u1, dept);
>       identitySession.getRoleManager().createRole(developer, u2, dept);
>       
>       identitySession.getPersistenceManager().removeGroup(dept, true);
> ----------------------------------------------------------------------------------------------
> Exception stack:
> ------------------------------------
> Caused by: java.util.ConcurrentModificationException
>     at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
>     at java.util.HashMap$KeyIterator.next(HashMap.java:877)
>     at org.hibernate.collection.AbstractPersistentCollection$IteratorProxy.next(AbstractPersistentCollection.java:577)
>     at org.jboss.identity.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:500)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 09:29:02 2009
From: jira-events at lists.jboss.org (Guy Coleman (JIRA))
Date: Mon, 15 Jun 2009 09:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-200) Validation errors
 in jboss_5_1.xsd
In-Reply-To: <31399568.1242244606768.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12363865.1245072542285.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472077#action_12472077 ] 

Guy Coleman commented on JBMETA-200:
------------------------------------

Please update the copies on the web too (http://www.jboss.org/j2ee/schema etc)

> Validation errors in jboss_5_1.xsd
> ----------------------------------
>
>                 Key: JBMETA-200
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-200
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.0.CR17
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Wolfgang Knauf
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>             Fix For: 1.0.1.GA
>
>
> I tried to create a jboss.xml from jboss_5_1.xsd, using Eclipe/WebTools for validation. To achieve this, I picked newest "jboss_5_1.xsd" and "jboss_common_5_1.xsd"  from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/jboss-common_5_1.xsd) and added them to an eclipse web project. The files at http://www.jboss.org/j2ee/schema/ are much older and with more problems...
> This results in several problems:
> =================
> Import of "javaee_5.xsd"  in jboss_common_5_1.xsd does not point to the web location:
> <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>
> It should be:
> <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>
> =================
> Next one is in "jboss_5_1.xsd"
> cos-nonambig: "http://www.jboss.com/xml/ns/javaee":security-identity and "http://www.jboss.com/xml/ns/javaee":security-identity (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.	jboss_5_1.xsd
> Reason: Element  "security-identity" in "message-driven-beanType" is duplicate.
> Same issue was resolved for jboss_5_0.xsd: https://jira.jboss.org/jira/browse/JBMETA-185
> =================
> jboss_5_1.xsd contains this imports:
>    <xsd:include schemaLocation="jboss-common_5_1.xsd"/>
> It must point to a valid url: http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd
> ================
> And finally: the usage comment talk about "5.0" and "jboss_5_0.xsd", should be 5.1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 09:32:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Mon, 15 Jun 2009 09:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBID-129)
 java.util.ConcurrentModificationException in HibernateIdentityStoreImpl
 class
In-Reply-To: <8734936.1245070447420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7274343.1245072776586.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBID-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472078#action_12472078 ] 

Jeff Yu commented on JBID-129:
------------------------------

Not really,

It is trying to delete the Object when it is in the iterator.next() method.

like:

         for (HibernateIdentityObjectRelationship relationship : hibernateObject.getToRelationships())
         {
            relationship.getFromIdentityObject().getFromRelationships().remove(relationship);
            relationship.getToIdentityObject().getToRelationships().remove(relationship);

            hibernateSession.delete(relationship); // This is causing the error.
         }

> java.util.ConcurrentModificationException in HibernateIdentityStoreImpl class
> -----------------------------------------------------------------------------
>
>                 Key: JBID-129
>                 URL: https://jira.jboss.org/jira/browse/JBID-129
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: IDM
>    Affects Versions: idm-1.0.0.Alpha5
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> The test case for this error is:
>       Group dept = identitySession.getPersistenceManager().createGroup("sales-dept", GROUP);
>       User u1 = identitySession.getPersistenceManager().createUser("jeff1");
>       User u2 = identitySession.getPersistenceManager().createUser("jeff2");
>       RoleType developer = identitySession.getRoleManager().createRoleType("developer");
>       identitySession.getRoleManager().createRole(developer, u1, dept);
>       identitySession.getRoleManager().createRole(developer, u2, dept);
>       
>       identitySession.getPersistenceManager().removeGroup(dept, true);
> ----------------------------------------------------------------------------------------------
> Exception stack:
> ------------------------------------
> Caused by: java.util.ConcurrentModificationException
>     at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
>     at java.util.HashMap$KeyIterator.next(HashMap.java:877)
>     at org.hibernate.collection.AbstractPersistentCollection$IteratorProxy.next(AbstractPersistentCollection.java:577)
>     at org.jboss.identity.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:500)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 09:34:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Mon, 15 Jun 2009 09:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-129)
 java.util.ConcurrentModificationException in HibernateIdentityStoreImpl
 class
In-Reply-To: <8734936.1245070447420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29786283.1245072896506.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Yu resolved JBID-129.
--------------------------

    Resolution: Done


> java.util.ConcurrentModificationException in HibernateIdentityStoreImpl class
> -----------------------------------------------------------------------------
>
>                 Key: JBID-129
>                 URL: https://jira.jboss.org/jira/browse/JBID-129
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: IDM
>    Affects Versions: idm-1.0.0.Alpha5
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> The test case for this error is:
>       Group dept = identitySession.getPersistenceManager().createGroup("sales-dept", GROUP);
>       User u1 = identitySession.getPersistenceManager().createUser("jeff1");
>       User u2 = identitySession.getPersistenceManager().createUser("jeff2");
>       RoleType developer = identitySession.getRoleManager().createRoleType("developer");
>       identitySession.getRoleManager().createRole(developer, u1, dept);
>       identitySession.getRoleManager().createRole(developer, u2, dept);
>       
>       identitySession.getPersistenceManager().removeGroup(dept, true);
> ----------------------------------------------------------------------------------------------
> Exception stack:
> ------------------------------------
> Caused by: java.util.ConcurrentModificationException
>     at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
>     at java.util.HashMap$KeyIterator.next(HashMap.java:877)
>     at org.hibernate.collection.AbstractPersistentCollection$IteratorProxy.next(AbstractPersistentCollection.java:577)
>     at org.jboss.identity.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:500)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 10:50:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 15 Jun 2009 10:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6554) Update jboss-managed
	to 2.1.0.CR2
In-Reply-To: <15314038.1235757645175.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3476605.1245077456696.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene updated JBAS-6554:
----------------------------------

    Parent Issue: JBAS-6551  (was: JBAS-6157)


> Update jboss-managed to 2.1.0.CR2
> ---------------------------------
>
>                 Key: JBAS-6554
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6554
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Management services, ProfileService
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> I need to merge the JBAS-6285, platform mbeans managed components changes and update jboss-managed to 2.1.0.CR2. This is to track this until I have time as the 5.x work is the priority.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 10:50:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 15 Jun 2009 10:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-6157) Track component
	updates
In-Reply-To: <20221525.1225727061221.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23736314.1245077457031.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene closed JBAS-6157.
---------------------------------

    Resolution: Duplicate Issue


> Track component updates
> -----------------------
>
>                 Key: JBAS-6157
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6157
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>            Assignee: Dimitris Andreadis
>            Priority: Critical
>             Fix For: JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 10:50:57 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 15 Jun 2009 10:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6551) Track component
 updates - 6.0.0.M1
In-Reply-To: <25977400.1235687384535.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15753316.1245077457233.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene updated JBAS-6551:
----------------------------------

    Summary: Track component updates - 6.0.0.M1  (was: Track component updates - 6.0.0.Alpha1)


> Track component updates - 6.0.0.M1
> ----------------------------------
>
>                 Key: JBAS-6551
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6551
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Jason T. Greene
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 10:52:56 2009
From: jira-events at lists.jboss.org (Jonathan Halliday (JIRA))
Date: Mon, 15 Jun 2009 10:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7022) Upgrade JBossTS to
	4.6.1
Message-ID: <13199209.1245077576468.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade JBossTS to 4.6.1
------------------------

                 Key: JBAS-7022
                 URL: https://jira.jboss.org/jira/browse/JBAS-7022
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Jonathan Halliday
            Assignee: Jonathan Halliday




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 11:15:57 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 15 Jun 2009 11:15:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9875646.1245078957244.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Kabir Khan commented on JBAS-6888:
----------------------------------

Assuming that clazz.getDeclaringClass() is called only in the generated advisor constructor, in GeneratedAdvisorInstrumentor.createAdvisorCtors(), maybe the string should be something like the following

   protected void createAdvisorCtors(CtClass clazz)throws CannotCompileException, NotFoundException
   {
      String initBody =
         "{" +
         "   java.lang.String domainName = org.jboss.aop.Domain.getDomainName(" + clazz.getName() + ".class, $2);" + 
         "   " + DOMAIN + "= new org.jboss.aop.GeneratedAdvisorDomain($1, domainName, " + clazz.getName() + ".class, $2); " +
         "   ((org.jboss.aop.Domain)" + DOMAIN + ").setInheritsBindings(true); " +
         "   super.initialise(" + clazz.getName() + ".class, " + DOMAIN + ");" +
         "}";
}

instead of
   protected void createAdvisorCtors(CtClass clazz)throws CannotCompileException, NotFoundException
   {
      String initBody =
         "{" +
         "   java.lang.String domainName = org.jboss.aop.Domain.getDomainName(" + DECLARING_CLASS + ", $2);" + 
         "   " + DOMAIN + "= new org.jboss.aop.GeneratedAdvisorDomain($1, domainName, " + DECLARING_CLASS + ", $2); " +
         "   ((org.jboss.aop.Domain)" + DOMAIN + ").setInheritsBindings(true); " +
         "   super.initialise(" + DECLARING_CLASS + ", " + DOMAIN + ");" +
         "}";
   }

> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Flavia Rainone
>         Attachments: server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 11:23:57 2009
From: jira-events at lists.jboss.org (Stefan Anzinger (JIRA))
Date: Mon, 15 Jun 2009 11:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-991) ReceiveLocalMessages
 does not work on MuxChannel
Message-ID: <22126121.1245079437238.JavaMail.jira@cloud.prod.atl2.jboss.com>

ReceiveLocalMessages does not work on MuxChannel
------------------------------------------------

                 Key: JGRP-991
                 URL: https://jira.jboss.org/jira/browse/JGRP-991
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.6.10
         Environment: RHEL4 Linux/Windows XP
            Reporter: Stefan Anzinger
            Assignee: Bela Ban


Setting receive local messages to false does not work on Multiplex Channels. Reason for this is, that the local_addr is not set on multiplex channels - therefore the mux channel cannot decide whether this message comes from local or not.

See attached a small testcase. The testcase just gets the local_addr from the "physical channel" and puts it into the MuxChannel local_addr via reflection.
Here is the testcase:

import java.io.ByteArrayInputStream;
import java.lang.reflect.Field;
import org.w3c.dom.*;
import javax.xml.parsers.*;
import junit.framework.TestCase;
import org.jgroups.*;
import org.jgroups.mux.Multiplexer;

public class TestJGroups extends TestCase {
    /**
     * Tests the receiveLocalMessages feature on multiplex
     * channels.
     * 
     * <h2>Course of action</h2>
     * <ol>
     *   <li>Creates tow physical channels</li>
     *   <li>For each physical channel a mux channel is created</li>
     *   <li>Receive Local messages is turned off on the mux channels</li>
     *   <li>Local address has to be set manually after connecting the physical channels (This may be done automatically)</li>
     *   <li>Message is sent from the first mux to the second mux channel</li>
     * </ol>
     * 
     * @throws Exception
     */
    public void testMultiplex() throws Exception {
        JChannelFactory factory = new JChannelFactory(getConfig());
        JChannel c1 = newChannel("c1", (JChannel)factory.createChannel());
        JChannel c2 = newChannel("c2", (JChannel)factory.createChannel());

        JChannel mc1 = newMuxChannel(c1, "mc1");
        JChannel mc2 = newMuxChannel(c2, "mc2");

        mc1.setOpt(Channel.LOCAL, Boolean.FALSE);
        mc2.setOpt(Channel.LOCAL, Boolean.FALSE);
        mc1.connect("X");
        mc2.connect("Y");

        // By commenting this, the messages are also received locally
        setLocalAddress(c1, mc1);   
        setLocalAddress(c2, mc2);
        
        Thread.sleep(2000);
        
        mc1.send(new Message(null, null, "HELLO WORLD"));
        
        Thread.sleep(500);
        
        c2.disconnect();
        c1.disconnect();
    }
    
    private JChannel newMuxChannel(JChannel channel, String name) throws Exception {
        Multiplexer mux = new Multiplexer(channel);
        JChannel mc = (JChannel)mux.createMuxChannel("hello1", "ASDF2");
        
        mc.setOpt(Channel.LOCAL, Boolean.FALSE);
        return newChannel(name, mc);
    }
    
    private void setLocalAddress(JChannel parent, JChannel mux) throws Exception {
        // local_addr Needs to be set, unless the "Ignore local messages" feature would not work.
        Field f = org.jgroups.JChannel.class.getDeclaredField("local_addr");
        f.setAccessible(true);
        f.set(mux, parent.getLocalAddress());
    }
    
    private JChannel newChannel(final String id, final JChannel c1) throws Exception
    {
        c1.setReceiver(new ReceiverAdapter() {
            @Override
            public void receive(Message msg) {
                super.receive(msg);
                System.out.println(id + " Received message: " + msg + " msg: " + msg.getObject());
            }
            @Override
            public void viewAccepted(View new_view) {
//                try {
//                    Thread.sleep((int)(Math.random()*1000.0));
//                } catch (InterruptedException e) {
//                    throw new RuntimeException(e);
//                }
//                System.out.println(id + " New View (new_view): " + new_view);
//                System.out.println(id + " New View (Channel):  " + c1.getView());
            }
        });
        return c1;
    }
    
    private Element getConfig() throws Exception {
        String config = 
            "<config>                                                                           " +
            "  <UDP mcast_recv_buf_size=\"80000\" mcast_send_buf_size=\"150000\"                " +
            "      mcast_port=\"32233\" mcast_addr=\"228.0.0.1\"                                " +
            "      ip_ttl=\"32\"/>                                                              " +
            "  <PING/>                                                                          " +
            "  <FD_SOCK/>                                                                       " +
            "  <VERIFY_SUSPECT timeout=\"15000\"/>                                               " +
            "  <pbcast.NAKACK gc_lag=\"50\" retransmit_timeout=\"300,600,1200,2400,48000\"/>     " +
            "  <UNICAST timeout=\"600,1200,2000,25000\"/>                                        " +
            "  <FRAG frag_size=\"8096\"/>                                                       " +
            "  <pbcast.STABLE desired_avg_gossip=\"20000\" max_bytes=\"500000\"/>               " +
            "  <pbcast.GMS print_local_addr=\"true\" join_timeout=\"60000\" shun=\"true\" />     " +
            "</config>                                                                          ";
        
        DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
        DocumentBuilder db = dbf.newDocumentBuilder();
        Document d = db.parse(new ByteArrayInputStream(config.getBytes()));
        return d.getDocumentElement();
    }
}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 11:56:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Mon, 15 Jun 2009 11:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13775671.1245081416919.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson commented on JBWEB-144:
------------------------------------

Cummulative change set for this patch 6.0.13 --> 6.0.19:
562807
658470
677728
677729
685699
685701
685708
698887
698913
698918
714256

Based on changes for individual affected files 6.0.13 --> 6.0.19:
========================================
1) ELParser.jtt:
658470
677728
685699
685701
698887
698913
698918
714256

2) ELParser.java:
562807
658470
677729
685708
698918
714256 

3) ELParserConstants.java:
562807
658470
677729
685708
714256 

4) ELParserTokenManger.java:
562807
658470
677729
685708
714256

> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 12:18:56 2009
From: jira-events at lists.jboss.org (Marco Ghanitab (JIRA))
Date: Mon, 15 Jun 2009 12:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2123) issue with the
 call of a drl function
Message-ID: <1390184.1245082736749.JavaMail.jira@cloud.prod.atl2.jboss.com>

issue with the call of a drl function
-------------------------------------

                 Key: JBRULES-2123
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2123
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Marco Ghanitab
            Assignee: Mark Proctor
            Priority: Minor


in a drl file with a rule "reset" ad a function "formatDate",a bad behaviour is verified when is called the function in the "when" block..it call the function many times, but if the function called is stored in a external java file (not drl) everything works fine, and it call the function only 2 times (correct).
Here the code of the drl file:


rule "reset"
        when
                $conversation:Conversation(resource.code == "sms", tickets.size > 0)
                not Discount(date == (formatDate($conversation.getStopDate())))
        then 
                Discount discount = new Discount();
                discount.setDate(formatDate($conversation.getStopDate()));
                discount.setQuantity(495);
                insert(discount);               
                System.out.println("reset " + discount.getDate());
end
 
declare Discount
   date : String
   quantity : int
end
 
function String formatDate(java.util.Date date) {
        java.text.SimpleDateFormat formatter = new java.text.SimpleDateFormat("dd/MM/yy");
        return formatter.format(date);
}




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 12:23:07 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 15 Jun 2009 12:23:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBVFS-114) Abstract zip reading
Message-ID: <20028343.1245082987027.JavaMail.jira@cloud.prod.atl2.jboss.com>

Abstract zip reading
--------------------

                 Key: JBVFS-114
                 URL: https://jira.jboss.org/jira/browse/JBVFS-114
             Project: JBoss VFS
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.2.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: 2.2.0.Alpha


Zip reading should be abstracted in order to be able to plug in other reader implementations.
e.g. DML' jzipfile or truezip

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 12:26:56 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Mon, 15 Jun 2009 12:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7023) Web Beans
 integration points container task
Message-ID: <1066442.1245083216361.JavaMail.jira@cloud.prod.atl2.jboss.com>

Web Beans integration points container task
-------------------------------------------

                 Key: JBAS-7023
                 URL: https://jira.jboss.org/jira/browse/JBAS-7023
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Web Beans
            Reporter: Pete Muir
            Assignee: Pete Muir
             Fix For: JBossAS-5.2.0.Beta1


Container task for Web Beans integration tasks to allow JBoss AS to fully pass TCK

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 12:28:56 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Mon, 15 Jun 2009 12:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7023) Web Beans
 integration points container task
In-Reply-To: <1066442.1245083216361.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10541917.1245083336485.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Pete Muir commented on JBAS-7023:
---------------------------------

Once a component upgrade task is created, we need to add a upgrade Javassist 3.11.0 task.

> Web Beans integration points container task
> -------------------------------------------
>
>                 Key: JBAS-7023
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7023
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Beans
>            Reporter: Pete Muir
>            Assignee: Pete Muir
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Container task for Web Beans integration tasks to allow JBoss AS to fully pass TCK

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 12:45:09 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Mon, 15 Jun 2009 12:45:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17035648.1245084309063.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-144:
-------------------------------

    Comment: was deleted


> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 12:45:08 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Mon, 15 Jun 2009 12:45:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13415378.1245084308839.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson commented on JBWEB-144:
------------------------------------

Cummulative change set for this patch 6.0.13 --> 6.0.19:
562807
578466
578610
658470
607334
649195
677728
677729
685699
685701
685708
698887
698913
698918
714256

Based on changes for individual affected files 6.0.13 --> 6.0.19:
========================================
1) ELParser.jtt:
658470
677728
685699
685701
698887
698913
698918
714256

2) ELParser.java:
562807
658470
677729
685708
698918
714256

3) ELParserConstants.java:
562807
658470
677729
685708
714256

4) ELParserTokenManger.java:
562807
658470
677729
685708
714256

5) EvaluationContext.java
607334
698887

6) FunctionMapperImpl.java
578466
578610
649195
698887

> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 13:31:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 15 Jun 2009 13:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7010)
 JndiLoginInitialContextFactory is
 not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18739028.1245087116560.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-7010:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 13:47:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 15 Jun 2009 13:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18935442.1245088076659.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer commented on JBAS-7008:
------------------------------------

I've deployed an EJB3 entity bean, and the corresponding MBean in the jmx-console (jboss.j2ee:jar=entity-test.jar,name=EntityTestBean,service=EJB3) contains the following metrics:

CreateCount  	R  	int  	MBean Attribute.  	
InvokeStats 	R 	org.jboss.ejb3.statistics.InvocationStatistics 	MBean Attribute. 	
CurrentSize 	R 	int 	MBean Attribute. 	
RemoveCount 	R 	int 	MBean Attribute. 	
MaxSize 	R 	int 	MBean Attribute. 	
AvailableCount    R   int   MBean Attribute. 	

Can we expose these same metrics via the Entity Bean ManagedObject?


> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 13:49:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Mon, 15 Jun 2009 13:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6939) after stopping a
 Topic or Queue
 via the stop operation, calling getRunState() on the corresponding
 component returns RunState.RUNNING, rather than RunState.STOPPED
In-Reply-To: <3464546.1242671225528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9140947.1245088196600.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Emanuel Muckenhuber resolved JBAS-6939.
---------------------------------------

    Resolution: Done


> after stopping a Topic or Queue via the stop operation, calling getRunState() on the corresponding component returns RunState.RUNNING, rather than RunState.STOPPED
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6939
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6939
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Ian Springer
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 14:05:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 15 Jun 2009 14:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-34) Container Task:
 Formalize Kerberos offering
In-Reply-To: <33197347.1173287004217.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21141583.1245089156752.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed SECURITY-34.
---------------------------------

    Resolution: Done


JBoss Negotiation does an awesome job.

use it standalone - or as part of JBAS5.1.0++

> Container Task: Formalize Kerberos offering
> -------------------------------------------
>
>                 Key: SECURITY-34
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-34
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 1.x, 2.0.GA
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: NO_VERSION
>
>
> Spoken to Chris Delashmutt about formalizing the initial work he did for Kerberos/spnego.
> http://wiki.jboss.org/wiki/Wiki.jsp?page=NegotiateKerberos
> This jira task is a container task for overall kerberos silent authentication tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 14:19:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Mon, 15 Jun 2009 14:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6753219.1245089996749.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-144:
-------------------------------

    Attachment: jbweb-144.patch


Proposed CP branch patch from this chain of patches:
1) svn diff -r 562806:562807 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 562807.patch
2) svn diff -r 578465:578466 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 578466.patch
3) svn diff -r 578609:578610 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 578610.patch
4) svn diff -r 607333:607334 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 607334.patch
5) svn diff -r 649194:649195 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 649195.patch
6) svn diff -r 658469:658470 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 658470.patch
7) svn diff -r 677727:677728 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 677728.patch
8) svn diff -r 677728:677729 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 677729.patch
9) svn diff -r 685698:685699 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 685699.patch
10) svn diff -r 685700:685701 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 685701.patch
11) svn diff -r 685707:685708 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 685708.patch
12) svn diff -r 698886:698887 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 698887.patch
13) svn diff -r 698912:698913 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 698913.patch
14) svn diff -r 698917:698918 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 698918.patch
15) svn diff -r 714255:714256 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 714256.patch

Would it be better, given the extent of changes, to rebase some part of the code (e.g. org.apache.el) to 6.0.19?

> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-144.patch, test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 14:25:56 2009
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 15 Jun 2009 14:25:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32668632.1245090356513.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Remy Maucherat commented on JBWEB-144:
--------------------------------------

Yes, EL got fixed, then refixed, then rerefixed. As the package is quite self contained, rebasing should be easy.

> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-144.patch, test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 15:20:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 15 Jun 2009 15:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-415) ClientLoginModule
 multi-threaded=false should make SecurityContext
 client side association
In-Reply-To: <12517767.1244524256604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31035966.1245093656926.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed SECURITY-415.
----------------------------------

    Resolution: Done


> ClientLoginModule multi-threaded=false should make SecurityContext client side association
> ------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-415
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-415
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.3.SP1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: 2.0.3.SP2
>
>
> The ClientLoginModule multi-threaded=false option when missing, should set SecurityContextAssociation.setClient()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 15:27:57 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Mon, 15 Jun 2009 15:27:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18989079.1245094077346.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-142:
-------------------------------

    Attachment: jbweb-142.patch


Proposed patch for CP branch. Let me know if this is acceptable.

Do we want to put this anywhere upstream (e.g. trunk, 2.1.x branch, etc.)?

> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-142.patch
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 16:29:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Mon, 15 Jun 2009 16:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREFLECT-3) Use an appropriate
 Javassist ClassPool
In-Reply-To: <12331947.1165415635891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3767544.1245097796718.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Flavia Rainone updated JBREFLECT-3:
-----------------------------------

        Summary: Use an appropriate Javassist ClassPool  (was: Use the ScopedClassPool from javassist)
    Description: 
The javassist reflection utilities use the original shared classpool.
This does not understand classloaders.

This should be updated to use a more appropriate ClassPool.

Good starting points are the  ScopedClassPool from Javassist and the ClassPools from JBossAOP (check AOPClassPool and ClassPool implementations at jboss-aop-asintegration-* subprojects.

  was:
The javassist reflection utilities use the original shared classpool.
This does not understand classloaders.

This should be updated to use the newer ScopedClassPool from javassist.



> Use an appropriate Javassist ClassPool
> --------------------------------------
>
>                 Key: JBREFLECT-3
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-3
>             Project: JBoss Reflection
>          Issue Type: Task
>          Components: Javassist
>            Reporter: Adrian Brock
>            Assignee: Flavia Rainone
>
> The javassist reflection utilities use the original shared classpool.
> This does not understand classloaders.
> This should be updated to use a more appropriate ClassPool.
> Good starting points are the  ScopedClassPool from Javassist and the ClassPools from JBossAOP (check AOPClassPool and ClassPool implementations at jboss-aop-asintegration-* subprojects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 16:31:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Mon, 15 Jun 2009 16:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREFLECT-3) Use an appropriate
 Javassist ClassPool
In-Reply-To: <12331947.1165415635891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28668132.1245097916663.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Flavia Rainone updated JBREFLECT-3:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237746


> Use an appropriate Javassist ClassPool
> --------------------------------------
>
>                 Key: JBREFLECT-3
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-3
>             Project: JBoss Reflection
>          Issue Type: Task
>          Components: Javassist
>            Reporter: Adrian Brock
>            Assignee: Flavia Rainone
>
> The javassist reflection utilities use the original shared classpool.
> This does not understand classloaders.
> This should be updated to use a more appropriate ClassPool.
> Good starting points are the  ScopedClassPool from Javassist and the ClassPools from JBossAOP (check AOPClassPool and ClassPool implementations at jboss-aop-asintegration-* subprojects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 16:46:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Mon, 15 Jun 2009 16:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREFLECT-54) Implement the
 Expression Interfaces
Message-ID: <3249894.1245098816505.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement the Expression Interfaces
-----------------------------------

                 Key: JBREFLECT-54
                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-54
             Project: JBoss Reflection
          Issue Type: Task
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone


The expressio interfaces should be implemented, allowing instrumentation of "Javassist expressions" through JBoss Reflection API.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 21:13:56 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Mon, 15 Jun 2009 21:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-4)
 AnnotationMergedView ignores
 annotated beans when xml does not define beans
In-Reply-To: <32782915.1200391879117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25747956.1245114836981.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472245#action_12472245 ] 

Richard Kennard commented on JBMETA-4:
--------------------------------------

Please note, as of the version of JBoss Metadata shipped with JBoss 5.1.0.GA:

You see this 'JBMETA-4' warning (and your annotated beans do not properly deploy) if you forget to put proper namespaces on the ejb-jar.xml. It should be...

<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">

...not just...

<ejb-jar>



> AnnotationMergedView ignores annotated beans when xml does not define beans
> ---------------------------------------------------------------------------
>
>                 Key: JBMETA-4
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-4
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.0.Beta5
>            Reporter: Carlo de Wolf
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>             Fix For: 1.0.0.Beta6
>
>
> AnnotationMergedView.merge(EnterpriseBeansMetaData merged, EnterpriseBeansMetaData xml, EnterpriseBeansMetaData annotation)
> falls through without doing anything if xml is null.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 22:29:08 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 15 Jun 2009 22:29:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22082632.1245119348362.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-7008:
-------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Complexity: Low


> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 02:49:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 16 Jun 2009 02:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-991) ReceiveLocalMessages
 does not work on MuxChannel
In-Reply-To: <22126121.1245079437238.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28006364.1245134996565.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban closed JGRP-991.
-------------------------

    Resolution: Won't Fix


Hi Stefan,

thanks for the bug report and test case ! However, as the Multiplexer has been deprecated and is not supported any longer, we won't fix this bug. Multiplexer will be removed in 3.0, use a shared transport instead.

If you absolutely need to use the Multiplexer in 2.6.x, reopen this issue and attach a patch, which I'll then apply.

> ReceiveLocalMessages does not work on MuxChannel
> ------------------------------------------------
>
>                 Key: JGRP-991
>                 URL: https://jira.jboss.org/jira/browse/JGRP-991
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.10
>         Environment: RHEL4 Linux/Windows XP
>            Reporter: Stefan Anzinger
>            Assignee: Bela Ban
>
> Setting receive local messages to false does not work on Multiplex Channels. Reason for this is, that the local_addr is not set on multiplex channels - therefore the mux channel cannot decide whether this message comes from local or not.
> See attached a small testcase. The testcase just gets the local_addr from the "physical channel" and puts it into the MuxChannel local_addr via reflection.
> Here is the testcase:
> import java.io.ByteArrayInputStream;
> import java.lang.reflect.Field;
> import org.w3c.dom.*;
> import javax.xml.parsers.*;
> import junit.framework.TestCase;
> import org.jgroups.*;
> import org.jgroups.mux.Multiplexer;
> public class TestJGroups extends TestCase {
>     /**
>      * Tests the receiveLocalMessages feature on multiplex
>      * channels.
>      * 
>      * <h2>Course of action</h2>
>      * <ol>
>      *   <li>Creates tow physical channels</li>
>      *   <li>For each physical channel a mux channel is created</li>
>      *   <li>Receive Local messages is turned off on the mux channels</li>
>      *   <li>Local address has to be set manually after connecting the physical channels (This may be done automatically)</li>
>      *   <li>Message is sent from the first mux to the second mux channel</li>
>      * </ol>
>      * 
>      * @throws Exception
>      */
>     public void testMultiplex() throws Exception {
>         JChannelFactory factory = new JChannelFactory(getConfig());
>         JChannel c1 = newChannel("c1", (JChannel)factory.createChannel());
>         JChannel c2 = newChannel("c2", (JChannel)factory.createChannel());
>         JChannel mc1 = newMuxChannel(c1, "mc1");
>         JChannel mc2 = newMuxChannel(c2, "mc2");
>         mc1.setOpt(Channel.LOCAL, Boolean.FALSE);
>         mc2.setOpt(Channel.LOCAL, Boolean.FALSE);
>         mc1.connect("X");
>         mc2.connect("Y");
>         // By commenting this, the messages are also received locally
>         setLocalAddress(c1, mc1);   
>         setLocalAddress(c2, mc2);
>         
>         Thread.sleep(2000);
>         
>         mc1.send(new Message(null, null, "HELLO WORLD"));
>         
>         Thread.sleep(500);
>         
>         c2.disconnect();
>         c1.disconnect();
>     }
>     
>     private JChannel newMuxChannel(JChannel channel, String name) throws Exception {
>         Multiplexer mux = new Multiplexer(channel);
>         JChannel mc = (JChannel)mux.createMuxChannel("hello1", "ASDF2");
>         
>         mc.setOpt(Channel.LOCAL, Boolean.FALSE);
>         return newChannel(name, mc);
>     }
>     
>     private void setLocalAddress(JChannel parent, JChannel mux) throws Exception {
>         // local_addr Needs to be set, unless the "Ignore local messages" feature would not work.
>         Field f = org.jgroups.JChannel.class.getDeclaredField("local_addr");
>         f.setAccessible(true);
>         f.set(mux, parent.getLocalAddress());
>     }
>     
>     private JChannel newChannel(final String id, final JChannel c1) throws Exception
>     {
>         c1.setReceiver(new ReceiverAdapter() {
>             @Override
>             public void receive(Message msg) {
>                 super.receive(msg);
>                 System.out.println(id + " Received message: " + msg + " msg: " + msg.getObject());
>             }
>             @Override
>             public void viewAccepted(View new_view) {
> //                try {
> //                    Thread.sleep((int)(Math.random()*1000.0));
> //                } catch (InterruptedException e) {
> //                    throw new RuntimeException(e);
> //                }
> //                System.out.println(id + " New View (new_view): " + new_view);
> //                System.out.println(id + " New View (Channel):  " + c1.getView());
>             }
>         });
>         return c1;
>     }
>     
>     private Element getConfig() throws Exception {
>         String config = 
>             "<config>                                                                           " +
>             "  <UDP mcast_recv_buf_size=\"80000\" mcast_send_buf_size=\"150000\"                " +
>             "      mcast_port=\"32233\" mcast_addr=\"228.0.0.1\"                                " +
>             "      ip_ttl=\"32\"/>                                                              " +
>             "  <PING/>                                                                          " +
>             "  <FD_SOCK/>                                                                       " +
>             "  <VERIFY_SUSPECT timeout=\"15000\"/>                                               " +
>             "  <pbcast.NAKACK gc_lag=\"50\" retransmit_timeout=\"300,600,1200,2400,48000\"/>     " +
>             "  <UNICAST timeout=\"600,1200,2000,25000\"/>                                        " +
>             "  <FRAG frag_size=\"8096\"/>                                                       " +
>             "  <pbcast.STABLE desired_avg_gossip=\"20000\" max_bytes=\"500000\"/>               " +
>             "  <pbcast.GMS print_local_addr=\"true\" join_timeout=\"60000\" shun=\"true\" />     " +
>             "</config>                                                                          ";
>         
>         DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
>         DocumentBuilder db = dbf.newDocumentBuilder();
>         Document d = db.parse(new ByteArrayInputStream(config.getBytes()));
>         return d.getDocumentElement();
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 02:51:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 16 Jun 2009 02:51:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-992) JChannelFactory:
	remove
Message-ID: <24627559.1245135116701.JavaMail.jira@cloud.prod.atl2.jboss.com>

JChannelFactory: remove
-----------------------

                 Key: JGRP-992
                 URL: https://jira.jboss.org/jira/browse/JGRP-992
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.0


Users should inject a channel via other means than a JChannelFactory. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 03:33:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 16 Jun 2009 03:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-89) The parent of a
 ManagedComponent should be it's defining ManagedObject
Message-ID: <19872504.1245137636613.JavaMail.jira@cloud.prod.atl2.jboss.com>

The parent of a ManagedComponent should be it's defining ManagedObject
----------------------------------------------------------------------

                 Key: JBMAN-89
                 URL: https://jira.jboss.org/jira/browse/JBMAN-89
             Project: JBoss Managed
          Issue Type: Task
    Affects Versions: JBossMan.2.1.1.Beta3
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber
             Fix For: JBossMan.2.0.1.CR1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 03:38:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 16 Jun 2009 03:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-89) The parent of a
 ManagedComponent should be it's defining ManagedObject
In-Reply-To: <19872504.1245137636613.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29450509.1245137936439.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Emanuel Muckenhuber resolved JBMAN-89.
--------------------------------------

    Resolution: Done


> The parent of a ManagedComponent should be it's defining ManagedObject
> ----------------------------------------------------------------------
>
>                 Key: JBMAN-89
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-89
>             Project: JBoss Managed
>          Issue Type: Task
>    Affects Versions: JBossMan.2.1.1.Beta3
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossMan.2.0.1.CR1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 04:17:00 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?J=C3=BCrgen_Schiewe_=28JIRA=29?=)
Date: Tue, 16 Jun 2009 04:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2124) KnowledgeAgent
 should load
 knowledge bases directly from Resource (bypassing the ChangeSet)
Message-ID: <29623001.1245140220703.JavaMail.jira@cloud.prod.atl2.jboss.com>

KnowledgeAgent should load knowledge bases directly from Resource (bypassing the ChangeSet)
-------------------------------------------------------------------------------------------

                 Key: JBRULES-2124
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2124
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-api, drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: J?rgen Schiewe
            Assignee: Mark Proctor


We develop Drools based applications and use Guvnor as a a repository. Hard-coding the hostname where Guvnor runs is not an option for us because the names are different in each installation and we do not want to modify all the changeset.xml files for each deployment.

Instead we would pass one (or more) Resources to the KnowledgeAgent and let it do the monitoring. This would allow us to build URLs dynamically from our system environment configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Tue Jun 16 05:47:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Tue, 16 Jun 2009 05:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2125) Drools core
 multithreading issue
In-Reply-To: <26229278.1245145676528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <778684.1245145676733.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrey Nechaev updated JBRULES-2125:
------------------------------------

    Attachment: Main.java


Here is the attachement

> Drools core multithreading issue
> --------------------------------
>
>                 Key: JBRULES-2125
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2125
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: Java HotSpot v 1.6.0_06, WinXP SP3
>            Reporter: Andrey Nechaev
>            Assignee: Mark Proctor
>         Attachments: Main.java
>
>
> Attachement below is the code showing the problems. 
> The program hangs and nothing is displayed in the Console.
> If I put lines 10-11 before the line 6, I get a NullPointerException:
> Exception in thread "main" java.lang.NullPointerException
>             at org.drools.reteoo.ObjectSource.addObjectSink(ObjectSource.java:124)
> ...
> But, if I comment out the lines 2&3, everything works ok.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 05:47:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Tue, 16 Jun 2009 05:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2125) Drools core
 multithreading issue
Message-ID: <26229278.1245145676528.JavaMail.jira@cloud.prod.atl2.jboss.com>

Drools core multithreading issue
--------------------------------

                 Key: JBRULES-2125
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2125
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
         Environment: Java HotSpot v 1.6.0_06, WinXP SP3
            Reporter: Andrey Nechaev
            Assignee: Mark Proctor
         Attachments: Main.java

Attachement below is the code showing the problems. 

The program hangs and nothing is displayed in the Console.

If I put lines 10-11 before the line 6, I get a NullPointerException:

Exception in thread "main" java.lang.NullPointerException
            at org.drools.reteoo.ObjectSource.addObjectSink(ObjectSource.java:124)
...

But, if I comment out the lines 2&3, everything works ok.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 06:19:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 16 Jun 2009 06:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1850) Synchronizations
 registered on the tx depend on ordering
Message-ID: <4600779.1245147596442.JavaMail.jira@cloud.prod.atl2.jboss.com>

Synchronizations registered on the tx depend on ordering
--------------------------------------------------------

                 Key: EJBTHREE-1850
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1850
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf
            Priority: Critical
             Fix For: EAP 5




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 08:17:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 16 Jun 2009 08:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7017) Upgrade EJB3 to
	1.1.7
In-Reply-To: <8087911.1245054716478.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26416044.1245154676611.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai resolved JBAS-7017.
--------------------------------

    Resolution: Done


Done. r90248.

Note: The upgrade was partially done already when EJB3 1.1.8-Alpha1 was introduced into the component-matrix through a separate commit.

> Upgrade EJB3 to 1.1.7
> ---------------------
>
>                 Key: JBAS-7017
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7017
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> EJB3 1.1.7 version has been released. Update the AS to use this new version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 08:19:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 16 Jun 2009 08:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7018) Upgrade EJB3 to
	1.1.7
In-Reply-To: <25050850.1245054836512.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6975052.1245154796724.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai commented on JBAS-7018:
------------------------------------

The integration of EJB3 1.1.7 with AS trunk, hasn't yet been centrally tested on Hudson because of build issue http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157046

Once we test the release centrally on hudson, will upgrade the component-matrix appropriately.


> Upgrade EJB3 to 1.1.7
> ---------------------
>
>                 Key: JBAS-7018
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7018
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Update the AS to use the newly released EJB3 1.1.7 version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 08:19:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 16 Jun 2009 08:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2125) Drools core
 multithreading issue
In-Reply-To: <26229278.1245145676528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22852376.1245154796951.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli reassigned JBRULES-2125:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> Drools core multithreading issue
> --------------------------------
>
>                 Key: JBRULES-2125
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2125
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: Java HotSpot v 1.6.0_06, WinXP SP3
>            Reporter: Andrey Nechaev
>            Assignee: Edson Tirelli
>         Attachments: Main.java
>
>
> Attachement below is the code showing the problems. 
> The program hangs and nothing is displayed in the Console.
> If I put lines 10-11 before the line 6, I get a NullPointerException:
> Exception in thread "main" java.lang.NullPointerException
>             at org.drools.reteoo.ObjectSource.addObjectSink(ObjectSource.java:124)
> ...
> But, if I comment out the lines 2&3, everything works ok.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 08:21:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 16 Jun 2009 08:21:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1946) Deserializing a
 KnowledgeBase object throws a java.io.EOFException
In-Reply-To: <13586666.1233155564971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9209299.1245154917307.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli commented on JBRULES-1946:
----------------------------------------

Adding additional info by the user:

==============
Hello Rick,

I confirm, that implementations - DroolsObjectOutputStream and DroolsObjectInputStream work well, but it's not applicable in my case, because I depend on external component, that is responsible for storing my data and it uses standard serialization mechanisms. Of course, I may do some workarounds that for example first serialize the stream using Drools implementation and then pass it to the external component, but I prefer to try to do it as it should be. If I don't manage to, I will think about some other ways.

Anyway, thank you for your response and advice.

Best regards,
Przemys?aw R??ycki


> Deserializing a KnowledgeBase object throws a java.io.EOFException
> ------------------------------------------------------------------
>
>                 Key: JBRULES-1946
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1946
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions:  5.0.0.M4, 5.0.0.M5
>         Environment: Ubuntu 8.10
>            Reporter: Simon Kelly
>            Assignee: Edson Tirelli
>             Fix For: 5.0.1.FINAL
>
>         Attachments: drools.test.zip, DroolsTest.java, Sample.drl, Sample1.drl, Sandbox2.java
>
>
> A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file.
> java.io.EOFException
> 	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
> 	at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
> 	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
> 	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49)
> 	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227)
> 	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173)
> 	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at com.sample.DroolsTest.read(DroolsTest.java:75)
> 	at com.sample.DroolsTest.testIO(DroolsTest.java:50)
> 	at com.sample.DroolsTest.main(DroolsTest.java:40)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Tue Jun 16 08:58:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 16 Jun 2009 08:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-193) Provide a extended
 DeploymentVisitor which can be used for filtering out deployers
Message-ID: <10118475.1245157136971.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide a extended DeploymentVisitor which can be used for filtering out deployers
----------------------------------------------------------------------------------

                 Key: JBDEPLOY-193
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-193
             Project: JBoss Deployers
          Issue Type: Feature Request
          Components: deployer
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: jaikiran pai
            Assignee: jaikiran pai


The AbstractRealDeployerWithInput currently relies on a DeploymentVisitor for filtering out deployers while processing out a deployment unit. The DeploymentVisitor is responsible for specifying the "type" of attachment to  look for, in the unit, to decide whether the unit can be processed by the deployer. There are 2 short-comings with the current DeploymentVisitor:

1) A unit can have multiple attachments of the same type - This effectively means a deployer cannot specify which out of these n attachments, is it interested in. This results in the deployer being called multiple times for the same unit.

2) Because the AbstractRealDeployerWithInput relies on the type of the attachment, it is expensive:

protected <U> void deploy(DeploymentUnit unit, DeploymentVisitor<U> visitor) throws DeploymentException
   {
      if (visitor == null)
         throw new IllegalArgumentException("Null visitor.");

      List<U> visited = new ArrayList<U>();
      try
      {
         Set<? extends U> deployments = unit.getAllMetaData(visitor.getVisitorType());
...

unit.getAllMetaData internally iterates over all attachments to create collection of eligible attachments.

To improve this, an ExtendedDeploymentVisitor can be introduced which allows for a deployer to register itself for a specific attachment with name and the corresponding type of the attachment. A new deployer can then use this ExtendedDeploymentVisitor to efficiently process the deployment unit.
 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 09:24:57 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 16 Jun 2009 09:24:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-5417) Deployment from a
 Restarted
 Nodes(after Crash/Shutdown) in a Cluster does not Hot Deploys.
Message-ID: <21131664.1245158697323.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott Marlow updated JBAS-5417:
-------------------------------

    Assignee: Scott Marlow  (was: Scott Marlow)


> Deployment from a Restarted Nodes(after Crash/Shutdown) in a Cluster does not Hot Deploys.
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-5417
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5417
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: JBoss 4.0.2 running on Redhat enterprise Linux 2.4.21-15
>            Reporter: Hari Prasad Kuppuswamy
>            Assignee: Scott Marlow
>             Fix For: Backlog
>
>
> Hai, 
> I am currently using JBoss 4.0.2 and facing a problem with Cluster Hot Deployment with restarted nodes. 
> I have only two nodes,say NODE-1 & NODE-2 in my Cluster. 
> 1.Intially,two nodes are running with EAR deployed on them. 
> 2.Suddenly,NODE-2 Crashes and is shutdown. 
> 3.Now,NODE-2 is restarted after sometime & when it starts,it gets hot deployed. 
> Fine until now..... 
> 4.But when I undeploy EAR from NODE-2,NODE-1 also gets undeployed accordingly. 
> 5.So now when I redeploy the EAR from NODE-2,NODE-2 gets deployed but NODE-1 is not getting hot deployed. 
> Note:But when I do Step 5 from NODE-1 and deploy EAR from NODE-1,it gets hot deployed accross NODE-2. 
> Now Further ..... 
> Instead of the Step 4,5 above,consider the following scenario. 
> 4.Now,Node 1 also crashes and recovers after some time. 
> 5.So both the nodes are now in a restarted state in Cluster.When I undeploy EAR from NODE-2 or NODE-1,both the nodes gets undeployed accordingly. 
> 6.But now when I redeploy from any of the restarted NODE-1 or NODE-2,it does not get hot deployed.Only the node from which I deploy gets deployed.
>    I think that this is a critical path in a Production Environment. 
> Thanks, 
> Hari 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 09:24:59 2009
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 16 Jun 2009 09:24:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2126) Simulation and
 testing framwork
Message-ID: <24807269.1245158699830.JavaMail.jira@cloud.prod.atl2.jboss.com>

Simulation and testing framwork
-------------------------------

                 Key: JBRULES-2126
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2126
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-core
            Reporter: Mark Proctor
            Assignee: Mark Proctor
             Fix For: 5.1.0.M1


Api for full simulation and testing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 09:24:58 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 16 Jun 2009 09:24:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3023) Bad interaction
 between farming/ha proxies
Message-ID: <21249517.1245158698498.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott Marlow updated JBAS-3023:
-------------------------------

    Assignee: Scott Marlow  (was: Scott Marlow)


> Bad interaction between farming/ha proxies
> ------------------------------------------
>
>                 Key: JBAS-3023
>                 URL: https://jira.jboss.org/jira/browse/JBAS-3023
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Deployers
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>            Assignee: Scott Marlow
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> At least two forum thread indicate there is a problem with farmed deployments breaking ha proxy behavior when one application is undeployed:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=80011
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77986

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 09:24:59 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 16 Jun 2009 09:24:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCLUSTER-67) Proposal for new
 FarmMemberSingletonService
Message-ID: <13784767.1245158699472.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott Marlow updated JBCLUSTER-67:
----------------------------------

    Assignee: Scott Marlow  (was: Scott Marlow)


> Proposal for new FarmMemberSingletonService
> -------------------------------------------
>
>                 Key: JBCLUSTER-67
>                 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-67
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: Q4Y5
>         Environment: Jboss 4.0.3RC2
>            Reporter: Gabriele Garuglieri
>            Assignee: Scott Marlow
>            Priority: Minor
>         Attachments: FarmMemberSingletonService-withSync.zip, FarmMemberSingletonService.zip
>
>
> Here is the proposal for a new service that behaves like FarmMemberService for the farming part, but  deploys files only on one node of the cluster.
> It has the following features:
> 1- it is obtained extending org.jboss.ha.framework.server.FarmMemberService
> 2- since the hierarchy org.jboss.deployment.scanner.URLDeploymentScanner, org.jboss.ha.framework.server.FarmMemberService was not extendable without pratically duplicating all the scanner code or entering in an "if, if, if..." nightmare i thought to refactor both classes to allow easy extendability.
> 3- it is associated with org.jboss.ha.singleton.HASingletonController which controls the singleton activation in only one node of the cluster.
> 4- in the nodes where the singleton is stopped it simply farms  files in the controlled directories keeping them up to date with the other nodes
> 5- in the node where the singleton is started it behaves exactly like FarmMemberService
> 6- the singleton is always started in the first started node (HASingletonController behaviour)
> 7- if the active node is stopped the singleton is activated in the next node in startup order
> 8- the singleton may be stopped by stopping its controller (from web console) without shutting down the server and will be automatically activated in the next node in startup order
> 9- when the singleton is stopped without shutting down the node it immediately undeploys all the files and keeps the farming function active, the files will be deployed in the next  node where the singleton is started
> 10- if the singleton, stopped from console, is restarted in a node first in startup order than the node where the the service was restarted, it stops the service in the other node regaining its master status (HASingletonController behaviour)
> 11- while refactoring i introduced a small change in FarmMemberService behaviour: the scanner is now run before calling pullNewDeployments() so  this method is now able to check if files are up to date with coordinator node avoiding to always transfer files even when they are the same as those in coordinator node. For the rest the behaviour of both URLDeploymentScanner and FarmMemberService is not changed
> 12- while testing i corrected a couple of problems in org.jboss.ha.framework.server.ClusterFileTransfer.push():
> - the first is that the remotePushWriteFile procedure  is always called and when the cluster has only one active node this mean a lot useless work for each deployed file, this is bad overhead for large files. I introduced a control so that the push() proceeds only if the cluster has at least two nodes
> - the second is a real bug, the input.close() is missing and this in Windows systems locks the deployed files not allowing any longer to overwrite or delete them until the server is closed
> I hope this is accepted, because i plan to use it in my production env and i'd like to see it in official release
> Gabriele

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 09:24:58 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 16 Jun 2009 09:24:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-5416) An application that
 is "farm"
 undeployed from the cluster could come back into the cluster.
Message-ID: <16852087.1245158698769.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott Marlow updated JBAS-5416:
-------------------------------

    Assignee: Scott Marlow  (was: Scott Marlow)


> An application that is "farm" undeployed from the cluster could come back into the cluster.
> -------------------------------------------------------------------------------------------
>
>                 Key: JBAS-5416
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5416
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.0.GA, JBossAS-4.2.1.GA, JBossAS-4.2.2.GA
>         Environment: any
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: Backlog
>
>
> An application that is "farm" undeployed from the cluster could come back into the cluster.  Steps to reproduce:
> a. Create a cluster with more than one node.  Lets assume three server nodes named { node1, node2, node3 }
> b.  Deploy an application to the cluster, I used WineDemo.war.
> c.  Bring node3 down.
> d.  Delete WineDemo.war from the cluster.  Note that it didn't get deleted from node3's farm folder as node3 is down.
> e.  Bring node3 back up, WineDemo.war is still running on node3.
> The workaround for this issue is to manually remove WineDemo.war from node3 before bringing it back up.
> A secondary problem occurs you then bring node2 down and back up.  We will deploy WineDemo.war on node2 (pulled from node3).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 09:36:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 16 Jun 2009 09:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-990) Grammatical Error in
 log message: I'm being am suspected.
In-Reply-To: <15502315.1244833736783.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26696178.1245159416742.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban resolved JGRP-990.
---------------------------

    Resolution: Done


> Grammatical Error in log message: I'm being am suspected.
> ---------------------------------------------------------
>
>                 Key: JGRP-990
>                 URL: https://jira.jboss.org/jira/browse/JGRP-990
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.1
>         Environment: N/A
>            Reporter: Duane Olawsky
>            Assignee: Bela Ban
>            Priority: Trivial
>             Fix For: 2.4.7
>
>
> There is a grammatical error in the following log message:
> "WARN - I am the coord and I'm being am suspected -- will probably leave shortly"
> I suggest removing the second "am".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 10:04:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 16 Jun 2009 10:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-532) Ant tasks not
 passing properties correctly to AS dist build
Message-ID: <17089570.1245161096601.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ant tasks not passing properties correctly to AS dist build
-----------------------------------------------------------

                 Key: JBBUILD-532
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-532
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven Builds
            Reporter: Paul Gier
            Assignee: Paul Gier
             Fix For: Maven Build - Maint 2009


There is a problem passing properties through the antrun plugin and then to the maven ant tasks.  One of these is not passing system properties correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 10:06:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 16 Jun 2009 10:06:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1851) Investigate the
 failure
 org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
Message-ID: <10648726.1245161216783.JavaMail.jira@cloud.prod.atl2.jboss.com>

Investigate the failure org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
-------------------------------------------------------------------------------------

                 Key: EJBTHREE-1851
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1851
             Project: EJB 3.0
          Issue Type: Task
          Components: testsuite
    Affects Versions: 1.1.7
            Reporter: jaikiran pai
            Assignee: jaikiran pai


The org.jboss.ejb3.test.container.unit.ContainerTestCase consistently fails with:

javax.naming.NameNotFoundException: Stateful not bound
	at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
	at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
	at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
	at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
	at sun.rmi.transport.Transport$1.run(Transport.java:153)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
	at java.lang.Thread.run(Thread.java:595)
	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
	at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
	at javax.naming.InitialContext.lookup(InitialContext.java:351)
	at org.jboss.ejb3.test.container.unit.ContainerTestCase.testInvocationStatistics(ContainerTestCase.java:93)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
	at junit.extensions.TestSetup.run(TestSetup.java:27)




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 10:28:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 16 Jun 2009 10:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-532) Ant tasks not
 passing properties correctly to AS dist build
In-Reply-To: <17089570.1245161096601.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29912035.1245162536377.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Paul Gier commented on JBBUILD-532:
-----------------------------------

Looks like the system properties are being passed from maven to Ant (via the antrun plugin) without a problem.  So the issue is with Ant passing the system properties back to maven through the Ant tasks.

> Ant tasks not passing properties correctly to AS dist build
> -----------------------------------------------------------
>
>                 Key: JBBUILD-532
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-532
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - Maint 2009
>
>
> There is a problem passing properties through the antrun plugin and then to the maven ant tasks.  One of these is not passing system properties correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 10:58:08 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 16 Jun 2009 10:58:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1642) Make the
 java ee example runnable on windows
In-Reply-To: <22235800.1244482856551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23155497.1245164288566.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil reassigned JBMESSAGING-1642:
----------------------------------------

    Assignee: Andy Taylor  (was: Tim Fox)


> Make the java ee example runnable on windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-1642
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1642
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>         Attachments: build.xml
>
>
> The javaee examples are hard-coded for Linux (run.sh is used to start JBoss AS).
> For windows users, they have to manually edit the build files to sue run.bat instead.
> There is a note in the Beta1 release notes about that.
> The windows/linux difference should be parameterized so that the same build file
> could be used on both OSes.
> The windows file (*.bat) must also be checked to ensure they ends with  \r\n

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 10:58:08 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 16 Jun 2009 10:58:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1642) Make the java
 ee example runnable on windows
In-Reply-To: <22235800.1244482856551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4169371.1245164288267.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil updated JBMESSAGING-1642:
-------------------------------------

    Attachment: build.xml


build.xml for examples/jms/clustered-standalone to run the example on both
windows and un*x families


> Make the java ee example runnable on windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-1642
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1642
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>         Attachments: build.xml
>
>
> The javaee examples are hard-coded for Linux (run.sh is used to start JBoss AS).
> For windows users, they have to manually edit the build files to sue run.bat instead.
> There is a note in the Beta1 release notes about that.
> The windows/linux difference should be parameterized so that the same build file
> could be used on both OSes.
> The windows file (*.bat) must also be checked to ensure they ends with  \r\n

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 11:10:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 16 Jun 2009 11:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22801019.1245165056845.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark commented on JBAS-7010:
-------------------------------------

The problem is that the http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-security/5.1.0-SNAPSHOT/ contents are not being updated. When I tried to due a deploy from the eap branch its failing to compile, so the pom is out of date. I'm working on getting the snapshot updated.

> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 11:37:56 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Tue, 16 Jun 2009 11:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7024) results of
 list*Messages methods
 of Queues and Topics have wrong meta type definition
Message-ID: <744707.1245166676454.JavaMail.jira@cloud.prod.atl2.jboss.com>

results of list*Messages methods of Queues and Topics have wrong meta type definition
-------------------------------------------------------------------------------------

                 Key: JBAS-7024
                 URL: https://jira.jboss.org/jira/browse/JBAS-7024
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: JBAPP_5_0 rev90256
            Reporter: Lukas Krejci
            Priority: Critical


The MessageListMapper used to define the meta types on list*Messages() methods for Queues and Topics advertises that the resulting type will be:

CollectionMetaType[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]

however the meta type of the actual meta values obtained using collectionValue.getElements() is advertised as:

MapCompositeValue[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]

This discrepancy is affecting the admin console, Jopr and JON because the meta values values have different type than the advertised meta type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 11:37:56 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 16 Jun 2009 11:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7025) Do not rely on single
 "server/target/etc/deployers/metadata-deployer-jboss-beans.xml" list
Message-ID: <11404436.1245166676620.JavaMail.jira@cloud.prod.atl2.jboss.com>

Do not rely on single "server/target/etc/deployers/metadata-deployer-jboss-beans.xml" list
------------------------------------------------------------------------------------------

                 Key: JBAS-7025
                 URL: https://jira.jboss.org/jira/browse/JBAS-7025
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Deployers
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Scott Marlow
            Assignee: Ales Justin
            Priority: Minor
             Fix For: JBossAS-6.0.0.Alpha1


We should not rely on the single "server/target/etc/deployers/metadata-deployer-jboss-beans.xml" list.  Deployments should be self contained with proper jboss-scanning.xml (or whatever is necessary).  

This comes from development forum email.  Thread starts at http://lists.jboss.org/pipermail/jboss-development/2009-June/014537.html.  Also see http://lists.jboss.org/pipermail/jboss-development/2009-June/014599.html + http://lists.jboss.org/pipermail/jboss-development/2009-June/014603.html


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 11:44:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 16 Jun 2009 11:44:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <52677.1245167097384.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark reassigned JBAS-7010:
-----------------------------------

    Assignee: Paul Gier  (was: Scott M Stark)


I'm seeing the following when trying to deploy an updated snapshot;
[535][valkyrie: security]$ rm -rf /home/svn/repository.jboss.org/maven2/org/jboss/jbossas/jboss-as-system-jmx
[536][valkyrie: security]$ mvn -U package
[INFO] Scanning for projects...
WAGON_VERSION: 1.0-beta-2
[INFO] ------------------------------------------------------------------------
[INFO] Building JBoss Application Server Security
[INFO]    task-segment: [package]
[INFO] ------------------------------------------------------------------------
[INFO] snapshot org.jboss.jbossas:jboss-as-system-jmx:5.1.0-SNAPSHOT: checking for updates from snapshots.jboss.org
Downloading: http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-system-jmx/5.1.0-SNAPSHOT/jboss-as-system-jmx-5.1.0-20090107.041038-32.pom
3K downloaded
[WARNING] POM for 'org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.jboss.jbossas:jboss-as-system-jmx at Artifact [org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile]
[INFO] snapshot org.jboss.jbossas:jboss-as-j2se:5.1.0-SNAPSHOT: checking for updates from snapshots.jboss.org
Downloading: http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-system-jmx/5.1.0-SNAPSHOT/jboss-as-system-jmx-5.1.0-20090107.041038-32.jar
281K downloaded
[INFO] [enforcer:enforce {execution: ban-bad-dependencies}]
[WARNING] POM for 'org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.jboss.jbossas:jboss-as-system-jmx at Artifact [org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile]
[INFO] [enforcer:enforce {execution: enforce-java-maven-versions}]
[WARNING] POM for 'org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.jboss.jbossas:jboss-as-system-jmx at Artifact [org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile]
[INFO] [enforcer:enforce {execution: enforce-plugin-versions}]
[INFO] snapshot org.jboss.jbossas:jboss-as-component-matrix:5.1.0-SNAPSHOT: checking for updates from snapshots.jboss.org
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[WARNING] POM for 'org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.jboss.jbossas:jboss-as-system-jmx at Artifact [org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile]
[INFO] [compiler:compile]
[INFO] Compiling 67 source files to /Users/svn/JBossAS/branches/JBPAPP_5_0/security/target/classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/jce/JCEProviderServiceMBean.java:[31,7] cannot access org.jboss.system.Service
file org/jboss/system/Service.class not found
public interface JCEProviderServiceMBean extends ServiceMBean

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIContextEstablishment.java:[31,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIContextEstablishment.java:[32,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[34,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[35,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[36,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[37,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[38,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[39,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[40,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[46,46] package org.jboss.managed.api.ManagedOperation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[47,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[48,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[49,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[50,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[51,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[52,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[53,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[54,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityManager.java:[57,7] cannot access org.jboss.kernel.spi.dependency.KernelControllerContextAware
file org/jboss/kernel/spi/dependency/KernelControllerContextAware.class not found
public class JaasSecurityManager extends ServiceMBeanSupport

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBindingBean.java:[27,24] package org.apache.log4j does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBindingBean.java:[36,11] cannot find symbol
symbol  : class Logger
location: class org.jboss.security.integration.JNDIBindingBean

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[26,31] package org.jboss.aop.joinpoint does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[27,31] package org.jboss.aop.joinpoint does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[28,32] package org.jboss.dependency.spi does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[29,39] package org.jboss.kernel.spi.dependency does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordMaskManagement.java:[42,24] package org.apache.log4j does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[61,24] cannot find symbol
symbol  : class Invocation
location: class org.jboss.security.integration.password.PasswordLifecycleCallback

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[94,23] cannot find symbol
symbol  : class ControllerContext
location: class org.jboss.security.integration.password.PasswordLifecycleCallback

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[118,25] cannot find symbol
symbol  : class ControllerContext
location: class org.jboss.security.integration.password.PasswordLifecycleCallback

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[124,43] cannot find symbol
symbol  : class ControllerContext
location: class org.jboss.security.integration.password.PasswordLifecycleCallback

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordMaskManagement.java:[55,11] cannot find symbol
symbol  : class Logger
location: class org.jboss.security.integration.password.PasswordMaskManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[32,48] package org.jboss.aop.microcontainer.aspects.jmx does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[33,46] package org.jboss.managed.api.ManagedOperation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[34,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[35,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[36,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[37,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[38,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[39,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[32,48] package org.jboss.aop.microcontainer.aspects.jmx does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[33,46] package org.jboss.managed.api.ManagedOperation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[34,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[35,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[36,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[37,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[38,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[39,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[40,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[27,22] package javax.xml.bind does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[28,22] package javax.xml.bind does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[30,44] package org.jboss.deployers.vfs.spi.deployer does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[31,45] package org.jboss.deployers.vfs.spi.structure does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[32,25] package org.jboss.virtual does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[44,53] cannot find symbol
symbol: class JAXBDeployer
public class JAXBElementParsingDeployer<T,V> extends JAXBDeployer 

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[47,13] cannot find symbol
symbol  : class JAXBContext
location: class org.jboss.security.deployers.JAXBElementParsingDeployer<T,V>

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[88,26] cannot find symbol
symbol  : class VFSDeploymentUnit
location: class org.jboss.security.deployers.JAXBElementParsingDeployer<T,V>

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[88,50] cannot find symbol
symbol  : class VirtualFile
location: class org.jboss.security.deployers.JAXBElementParsingDeployer<T,V>

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JBossSecuritySubjectFactory.java:[29,29] package org.jboss.managed.api does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JBossSecuritySubjectFactory.java:[30,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JBossSecuritySubjectFactory.java:[31,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JBossSecuritySubjectFactory.java:[32,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JBossSecuritySubjectFactory.java:[33,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[24,22] package javax.xml.bind does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[25,22] package javax.xml.bind does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[27,31] package org.jboss.deployers.spi does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[28,41] package org.jboss.deployers.structure.spi does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[37,75] cannot find symbol
symbol: class JAXBElement
public class XacmlConfigParsingDeployer extends JAXBElementParsingDeployer<JAXBElement,PDP>

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[41,13] cannot find symbol
symbol  : class JAXBContext
location: class org.jboss.security.deployers.XacmlConfigParsingDeployer

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[74,33] cannot find symbol
symbol  : class DeploymentUnit
location: class org.jboss.security.deployers.XacmlConfigParsingDeployer

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[74,89] cannot find symbol
symbol  : class DeploymentException
location: class org.jboss.security.deployers.XacmlConfigParsingDeployer

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/AclConfigParsingDeployer.java:[24,44] package org.jboss.deployers.vfs.spi.deployer does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/AclConfigParsingDeployer.java:[27,25] package org.jboss.virtual does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/AclConfigParsingDeployer.java:[35,46] cannot find symbol
symbol: class SchemaResolverDeployer
public class AclConfigParsingDeployer extends SchemaResolverDeployer<ACLConfiguration>

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/AclConfigParsingDeployer.java:[44,36] cannot find symbol
symbol  : class VirtualFile
location: class org.jboss.security.deployers.AclConfigParsingDeployer

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIContextEstablishment.java:[43,1] cannot find symbol
symbol: class ManagementObject
@ManagementObject(name = "JNDIContextEstablishment", componentType = @ManagementComponent(

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[61,1] cannot find symbol
symbol: class ManagementObject
@ManagementObject(name="JNDIBasedSecurityManagement", componentType = @ManagementComponent(type = "MCBean", subtype = "Security"),

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[107,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[132,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[155,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[177,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[202,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[224,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[231,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[238,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[245,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[252,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[341,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[108,1] cannot find symbol
symbol: class ManagementObject
@ManagementObject(componentType = @ManagementComponent(type = "MCBean", subtype = "Security"), properties = ManagementProperties.EXPLICIT)

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[375,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[400,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[194,4] cannot find symbol
symbol  : class ManagementObjectID
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[195,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[206,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[227,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[252,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[263,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[284,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[305,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[329,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain


[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9 seconds
[INFO] Finished at: Tue Jun 16 08:43:18 PDT 2009
[INFO] Final Memory: 14M/26M
[INFO] ------------------------------------------------------------------------
[537][valkyrie: security]$ 


> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Paul Gier
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 12:29:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 16 Jun 2009 12:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1857046.1245169796753.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Paul Gier commented on JBAS-7010:
---------------------------------

I checked out the branch and built the whole thing from the root directory.  It built ok for me, so I'm deploying an update to the snapshot repository now.
Scott, it might have failed for you if you tried building only the security module since the snapshot dependencies that were being retrieved were so old.

Any reason you are not using the default local repo location (.m2/repository) ?  If you have your local repo and the svn checkout in the same place it might cause problems.

> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Paul Gier
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 13:36:56 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Tue, 16 Jun 2009 13:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7024) results of
 list*Messages methods
 of Queues and Topics have wrong meta type definition
In-Reply-To: <744707.1245166676454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15089523.1245173816498.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Lukas Krejci reassigned JBAS-7024:
----------------------------------

    Assignee: Jason T. Greene


> results of list*Messages methods of Queues and Topics have wrong meta type definition
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-7024
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7024
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBAPP_5_0 rev90256
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>            Priority: Critical
>
> The MessageListMapper used to define the meta types on list*Messages() methods for Queues and Topics advertises that the resulting type will be:
> CollectionMetaType[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> however the meta type of the actual meta values obtained using collectionValue.getElements() is advertised as:
> MapCompositeValue[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> This discrepancy is affecting the admin console, Jopr and JON because the meta values values have different type than the advertised meta type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 13:32:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 16 Jun 2009 13:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7026) EJB3Deployer should
 use post processed metadata instead of merged metadata
Message-ID: <4292241.1245173576566.JavaMail.jira@cloud.prod.atl2.jboss.com>

EJB3Deployer should use post processed metadata instead of merged metadata
--------------------------------------------------------------------------

                 Key: JBAS-7026
                 URL: https://jira.jboss.org/jira/browse/JBAS-7026
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: jaikiran pai
            Assignee: jaikiran pai


The EJB3Deployer currently uses merged metadata:

addInput(MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME);

This should be changed to use post processed metadata.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 13:48:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 16 Jun 2009 13:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-130)
 SOAPSAMLXACMLServlet:: PDP in init method and threadsafe evaluation
Message-ID: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>

SOAPSAMLXACMLServlet:: PDP in init method and threadsafe evaluation
-------------------------------------------------------------------

                 Key: JBID-130
                 URL: https://jira.jboss.org/jira/browse/JBID-130
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 15:34:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 16 Jun 2009 15:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-416)
 AnyURIAttribute->getInstance should trim the string value
Message-ID: <1137530.1245180896442.JavaMail.jira@cloud.prod.atl2.jboss.com>

AnyURIAttribute->getInstance should trim the string value
---------------------------------------------------------

                 Key: SECURITY-416
                 URL: https://jira.jboss.org/jira/browse/SECURITY-416
             Project: JBoss Security and Identity Management
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-sunxacml
    Affects Versions: JBossXACML_2.0.3
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: jbossxacml_2.0.3.SP1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 15:36:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 16 Jun 2009 15:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-416)
 AnyURIAttribute->getInstance should trim the string value
In-Reply-To: <1137530.1245180896442.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13378214.1245181016444.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed SECURITY-416.
----------------------------------

    Resolution: Done


> AnyURIAttribute->getInstance should trim the string value
> ---------------------------------------------------------
>
>                 Key: SECURITY-416
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-416
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-sunxacml
>    Affects Versions: JBossXACML_2.0.3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 15:59:07 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 16 Jun 2009 15:59:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-417) JBossXACML
	2.0.3.SP1
Message-ID: <11421202.1245182347889.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBossXACML 2.0.3.SP1
--------------------

                 Key: SECURITY-417
                 URL: https://jira.jboss.org/jira/browse/SECURITY-417
             Project: JBoss Security and Identity Management
          Issue Type: Release
      Security Level: Public (Everyone can see)
          Components: jboss-sunxacml, JBossXACML
    Affects Versions: JBossXACML_2.0.3
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: jbossxacml_2.0.3.SP1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:08:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 16 Jun 2009 16:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-417) JBossXACML
	2.0.3.SP1
In-Reply-To: <11421202.1245182347889.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21791070.1245182936573.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed SECURITY-417.
----------------------------------

    Resolution: Done


> JBossXACML 2.0.3.SP1
> --------------------
>
>                 Key: SECURITY-417
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-417
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: jboss-sunxacml, JBossXACML
>    Affects Versions: JBossXACML_2.0.3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:10:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 16 Jun 2009 16:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-417) JBossXACML
	2.0.3.SP1
In-Reply-To: <11421202.1245182347889.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32710786.1245183056498.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana commented on SECURITY-417:
----------------------------------------

 	 Bug  SECURITY-416 	 : AnyURIAttribute->getInstance should trim the string value  	  
   	Release  SECURITY-417:JBossXACML 2.0.3.SP1 	 
   	Bug   SECURITY-414 : XACML: ParsingException should also contain the real cause 

> JBossXACML 2.0.3.SP1
> --------------------
>
>                 Key: SECURITY-417
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-417
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: jboss-sunxacml, JBossXACML
>    Affects Versions: JBossXACML_2.0.3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:16:00 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Tue, 16 Jun 2009 16:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-735) Fix the
 2.0.x-compliance-tests.xml script
In-Reply-To: <8383897.1244526356637.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33514506.1245183360355.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Flavia Rainone closed JBAOP-735.
--------------------------------



> Fix the 2.0.x-compliance-tests.xml script
> -----------------------------------------
>
>                 Key: JBAOP-735
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-735
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>             Fix For: 2.1.2.GA
>
>
> Currently, if you try to run the precompiled-tests_2.0.x target, this is what you get:
> _run-precompiled-test_2.0.x:
>      [echo] Compiling bridgemethod with optimized=true and instrumentor ${instrumentor}
>      [aopc] Exception in thread "main" java.lang.RuntimeException: Invalid instrumentor ${instrumentor} was used
>      [aopc] 	at org.jboss.aop.instrument.InstrumentorFactory.initialise(InstrumentorFactory.java:75)
>      [aopc] 	at org.jboss.aop.AspectManager$1.run(AspectManager.java:317)
>      [aopc] 	at org.jboss.aop.AspectManager$1.run(AspectManager.java:263)
>      [aopc] 	at java.security.AccessController.doPrivileged(Native Method)
>      [aopc] 	at org.jboss.aop.AspectManager.initManager(AspectManager.java:262)
>      [aopc] 	at org.jboss.aop.AspectManager.instance(AspectManager.java:241)
>      [aopc] 	at org.jboss.aop.AspectManager.instance(AspectManager.java:230)
>      [aopc] 	at org.jboss.aop.standalone.Compiler.compile(Compiler.java:195)
>      [aopc] 	at org.jboss.aop.standalone.Compiler.main(Compiler.java:88)
> BUILD FAILED
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/build-tests-jdk50.xml:275: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:256: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:486: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:287: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:654: Java returned: 1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:16:00 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 16 Jun 2009 16:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7025) Do not rely on
 single
 "server/target/etc/deployers/metadata-deployer-jboss-beans.xml" list
In-Reply-To: <11404436.1245166676620.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24414483.1245183360911.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott Marlow reassigned JBAS-7025:
----------------------------------

    Assignee: Scott Marlow  (was: Ales Justin)


> Do not rely on single "server/target/etc/deployers/metadata-deployer-jboss-beans.xml" list
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7025
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7025
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>            Priority: Minor
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> We should not rely on the single "server/target/etc/deployers/metadata-deployer-jboss-beans.xml" list.  Deployments should be self contained with proper jboss-scanning.xml (or whatever is necessary).  
> This comes from development forum email.  Thread starts at http://lists.jboss.org/pipermail/jboss-development/2009-June/014537.html.  Also see http://lists.jboss.org/pipermail/jboss-development/2009-June/014599.html + http://lists.jboss.org/pipermail/jboss-development/2009-June/014603.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:21:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 16 Jun 2009 16:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2423) CMS search
 cannot handle empty search string
Message-ID: <32370284.1245183716450.JavaMail.jira@cloud.prod.atl2.jboss.com>

CMS search cannot handle empty search string
--------------------------------------------

                 Key: JBPORTAL-2423
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2423
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal CMS
    Affects Versions: 2.7.2 Final
            Reporter: Chris Laprun
            Assignee: Sohil Shah
             Fix For: 2.7.3 Final


Trying to search CMS for an empty String results in an exception...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:23:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 16 Jun 2009 16:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-130) SOAPSAMLXACMLServlet::
 PDP in init method and threadsafe evaluation
In-Reply-To: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12259656.1245183836752.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed JBID-130.
------------------------------

    Resolution: Done


> SOAPSAMLXACMLServlet:: PDP in init method and threadsafe evaluation
> -------------------------------------------------------------------
>
>                 Key: JBID-130
>                 URL: https://jira.jboss.org/jira/browse/JBID-130
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:38:56 2009
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Tue, 16 Jun 2009 16:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
Message-ID: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>

IllegalStateException upon cluster fail-over
--------------------------------------------

                 Key: JBMESSAGING-1657
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.0.SP3.CP05
            Reporter: Justin Bertram
            Assignee: Tim Fox


I set up two cluster nodes like so:

1) unzipped fresh JBoss EAP 4.3 CP04
2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
8) copied <JBOSS_HOME> to <JBOSS_HOME2>
9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"

Then I ran the test (which is attached as JmsTest.java)
 -Start test client connecting to 127.0.0.1
 -Observe client log filling up with "."
 -Drop JBoss running on 127.0.0.1
 -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
 -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:42:56 2009
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Tue, 16 Jun 2009 16:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11599990.1245184976893.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Justin Bertram updated JBMESSAGING-1657:
----------------------------------------

    Attachment: JmsTest.java
                127.0.0.1.log
                127.0.0.2.log


> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05
>            Reporter: Justin Bertram
>            Assignee: Tim Fox
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:42:57 2009
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Tue, 16 Jun 2009 16:42:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18296470.1245184977419.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Justin Bertram updated JBMESSAGING-1657:
----------------------------------------

    Description: 
I set up two cluster nodes like so:

1) unzipped fresh JBoss EAP 4.3 CP04
2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
8) copied <JBOSS_HOME> to <JBOSS_HOME2>
9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"

Then I ran the test (which is attached as JmsTest.java)
 -Start test client connecting to 127.0.0.1
 -Observe client log filling up with "."
 -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
 -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
 -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

  was:
I set up two cluster nodes like so:

1) unzipped fresh JBoss EAP 4.3 CP04
2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
8) copied <JBOSS_HOME> to <JBOSS_HOME2>
9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"

Then I ran the test (which is attached as JmsTest.java)
 -Start test client connecting to 127.0.0.1
 -Observe client log filling up with "."
 -Drop JBoss running on 127.0.0.1
 -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
 -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)



> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05
>            Reporter: Justin Bertram
>            Assignee: Tim Fox
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:42:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 16 Jun 2009 16:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30767693.1245184976717.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-7010.
---------------------------------

    Resolution: Done
      Assignee: Scott M Stark  (was: Paul Gier)


With Paul's refresh of the snapshots the ejb client is running without the authentication failure:

[506][valkyrie: jbas5-ejb-client]$ java -jar target/jbas5-ejb-client-1.0.jar 
Creating JNDI InitialContext with env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099/, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
Created JNDI InitialContext [javax.naming.InitialContext at be0e27].
Looking up name 'SecureProfileService/remote' from InitialContext...
Found Object: Proxy to jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3 implementing [interface org.jboss.profileservice.spi.ProfileService]
Looking up name 'SecureManagementView/remote' from InitialContext...
Found Object: Proxy to jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3 implementing [interface org.jboss.deployers.spi.management.ManagementView]
Looking up name 'SecureDeploymentManager/remote' from InitialContext...
Found Object: Proxy to jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3 implementing [interface org.jboss.deployers.spi.management.deploy.DeploymentManager]
[507][valkyrie: jbas5-ejb-client]$ 

> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:42:57 2009
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Tue, 16 Jun 2009 16:42:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18066360.1245184977186.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Justin Bertram updated JBMESSAGING-1657:
----------------------------------------

    Attachment: client.log


> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05
>            Reporter: Justin Bertram
>            Assignee: Tim Fox
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:51:20 2009
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Tue, 16 Jun 2009 16:51:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26928617.1245185480226.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Justin Bertram reassigned JBMESSAGING-1657:
-------------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


I'm assigning this to Howard as he is the 1.4.x maintainer.

> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 17:24:12 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 16 Jun 2009 17:24:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-532) Ant tasks not
 passing properties correctly to AS dist build
In-Reply-To: <17089570.1245161096601.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32586366.1245187452157.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Paul Gier commented on JBBUILD-532:
-----------------------------------

Created http://jira.codehaus.org/browse/MANTTASKS-153.

> Ant tasks not passing properties correctly to AS dist build
> -----------------------------------------------------------
>
>                 Key: JBBUILD-532
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-532
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - Maint 2009
>
>
> There is a problem passing properties through the antrun plugin and then to the maven ant tasks.  One of these is not passing system properties correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 18:01:11 2009
From: jira-events at lists.jboss.org (Richard Taylor (JIRA))
Date: Tue, 16 Jun 2009 18:01:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6314) Problems using EJB
 + Quartz + Seam
In-Reply-To: <29883538.1229034156614.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23960201.1245189671661.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Richard Taylor commented on JBAS-6314:
--------------------------------------

A potential workaround for this is to disable EAR classloading isolation (in ear-deployer-jboss-beans.xml).  It solved a very similar problem (non Seam) for us in JBoss 5.1.0.  Obviously this isn't an option for everyone.

> Problems using EJB + Quartz + Seam
> ----------------------------------
>
>                 Key: JBAS-6314
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6314
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows Vista
>            Reporter: Diego Coronel
>            Assignee: Andrew Lee Rubinger
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
>  problems using quartz/seam with AS5, it works fine in jboss 4.2.2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 19:50:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Tue, 16 Jun 2009 19:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREFLECT-3) Use an
 appropriate Javassist ClassPool
In-Reply-To: <12331947.1165415635891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30504405.1245196256816.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBREFLECT-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472412#action_12472412 ] 

Flavia Rainone commented on JBREFLECT-3:
----------------------------------------

Currently, I'm taking a very good look at all ClassPool implementations, from jassist.ClassPool to the aop-asintegration class pools. I think that after this is done, I'll have a better understanding of what does what and what belongs where. I'll post my thoughts & questions at the forum once I'm done with this research.

> Use an appropriate Javassist ClassPool
> --------------------------------------
>
>                 Key: JBREFLECT-3
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-3
>             Project: JBoss Reflection
>          Issue Type: Task
>          Components: Javassist
>            Reporter: Adrian Brock
>            Assignee: Flavia Rainone
>
> The javassist reflection utilities use the original shared classpool.
> This does not understand classloaders.
> This should be updated to use a more appropriate ClassPool.
> Good starting points are the  ScopedClassPool from Javassist and the ClassPools from JBossAOP (check AOPClassPool and ClassPool implementations at jboss-aop-asintegration-* subprojects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 20:03:05 2009
From: jira-events at lists.jboss.org (Alex Skor (JIRA))
Date: Tue, 16 Jun 2009 20:03:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6973) Starting JBoss AS
 5.1.0 fails on opensolaris, jdk 1.6.0_13
In-Reply-To: <18440810.1243287236718.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16248773.1245196985744.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Alex Skor commented on JBAS-6973:
---------------------------------

I see the same error on Sun OS (not opensolaris) with Sun JDK 1.5.0_18 and Jboss 5.1.0GA:
$uname -a
SunOS mars5 5.10 Generic_127127-11 sun4u sparc SUNW,SPARC-Enterprise


> Starting JBoss AS 5.1.0 fails on opensolaris, jdk 1.6.0_13
> ----------------------------------------------------------
>
>                 Key: JBAS-6973
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6973
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: System service
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: OpenSolaris build 111, running Sun Java 1.6.0_13
>            Reporter: Vincent De Baere
>            Assignee: Dimitris Andreadis
>            Priority: Minor
>         Attachments: as-5.1.0.GA-profile.xml.patch
>
>
> Starting up JBoss AS 5.1.0.GA fails with the following message:
> 23:31:11,553 INFO  [JMXKernel] Legacy JMX core initialized
> 23:31:16,747 ERROR [AbstractKernelController] Error installing to Instantiated: name=AttachmentStore state=Described
> java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[java.net.URI] actual=[java.io.File]
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:395)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:153)
> 	at org.jboss.reflect.plugins.introspection.ReflectConstructorInfoImpl.newInstance(ReflectConstructorInfoImpl.java:106)
> 	at org.jboss.joinpoint.plugins.BasicConstructorJoinPoint.dispatch(BasicConstructorJoinPoint.java:80)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.createTarget(AOPConstructorJoinpoint.java:282)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:103)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:66)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:319)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:297)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130)
> 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76)
> 	at org.jboss.bootstrap.microcontainer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:91)
> 	at org.jboss.bootstrap.microcontainer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:161)
> 	at org.jboss.bootstrap.microcontainer.ServerImpl.doStart(ServerImpl.java:138)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:450)
> 	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)
> Failed to boot JBoss:
> java.lang.IllegalStateException: Incompletely deployed:
> DEPLOYMENTS IN ERROR:
>   Deployment "AttachmentStore" is in error due to: java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[java.net.URI] actual=[java.io.File]
> DEPLOYMENTS MISSING DEPENDENCIES:
>   Deployment "ProfileService" is missing the following dependencies:
>     Dependency "jboss.kernel:service=KernelController" (should be in state "Installed", but is actually in state "**ERROR**")
>     Dependency "ProfileServiceDeployer" (should be in state "Installed", but is actually in state "Instantiated")
>   Deployment "ProfileServiceDeployer" is missing the following dependencies:
>     Dependency "AttachmentStore" (should be in state "Installed", but is actually in state "**ERROR**")
>   Deployment "ProfileServiceBootstrap" is missing the following dependencies:
>     Dependency "jboss.kernel:service=Kernel" (should be in state "Installed", but is actually in state "**ERROR**")
>     Dependency "ProfileService" (should be in state "Installed", but is actually in state "Instantiated")
>   Deployment "ProfileServicePersistenceDeployer" is missing the following dependencies:
>     Dependency "AttachmentStore" (should be in state "Installed", but is actually in state "**ERROR**")
> 	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.microcontainer.ServerImpl.doStart(ServerImpl.java:142)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:450)
> 	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)
> 23:31:18,389 INFO  [ServerImpl] Runtime shutdown hook called, forceHalt: true
> 23:31:18,402 INFO  [ServerImpl] Shutdown complete
> Shutdown complete
> Halting VM

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 20:03:05 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Tue, 16 Jun 2009 20:03:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
Message-ID: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>

Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
------------------------------------------------------------------------------------------

                 Key: JBMETA-208
                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.0.1.GA
         Environment: JBoss AS 5.1.0.GA
            Reporter: Richard Kennard
            Assignee: Alexey Loubyansky


The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...

<ejb-jar>
</ejb-jar>

...instead of...

<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">
</ejb-jar>

...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.

An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...

http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html

...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 20:46:57 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Tue, 16 Jun 2009 20:46:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4032450.1245199617494.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Flavia Rainone commented on JBAS-6888:
--------------------------------------

I've tested Kabir suggestion and it works. Following Kabir's instructions, I'm creating a JBAOP associated with this Jira for the implementation of Kabir's fix.

> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Flavia Rainone
>         Attachments: server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 20:49:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Tue, 16 Jun 2009 20:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-736) Create workaround
 for IBM JVM's Clas.getDeclaringClass bug
Message-ID: <33122186.1245199796446.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create workaround for IBM JVM's Clas.getDeclaringClass bug
----------------------------------------------------------

                 Key: JBAOP-736
                 URL: https://jira.jboss.org/jira/browse/JBAOP-736
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.1.GA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: 2.1.2.GA


The IBM's JVM returns null when the generated advisor's constructor invokes this.getClass().getDeclaringClass(), thus causing JBoss AOP from version 2.0 on to not work with IBM's JVM.

The call to getDeclaringClass() needs to be replaced.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 00:28:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 17 Jun 2009 00:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1644) Work out a
 suitable way to provide JBM examples/doc for AS 5
In-Reply-To: <25933843.1244563136418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33358238.1245212936459.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1644:
-----------------------------------------

After discussion, we decide for the moment just put the examples to the JBoss Messaging download page and add a link to the upcoming AS5 release notes.



> Work out a suitable way to provide JBM examples/doc for AS 5
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1644
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1644
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.5.GA
>
>
> Current AS 5 distribution kit doesn't have JBM doc/examples of the corresponding version included, that makes it very inconvenient to use JBM with AS5. Users often get confused with which version of JBM is the correct version, and where to get the resouces (docs, examples).
> We have to provide a solution to that. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 02:05:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 17 Jun 2009 02:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2848448.1245218756832.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai commented on JBMETA-208:
-------------------------------------

Alexey,

I am not yet sure whether this is some issue with JBMETA or EJBTHREE (which probably picks up the deployment incorrectly starts spitting out the WARN messages). If it turns out to be an EJB3 issue please assign this to me.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 03:04:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 17 Jun 2009 03:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6777) 'interleaving' prop
 on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24333999.1245222296739.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-6777.
---------------------------------

    Resolution: Done


The reflection info was marking the interleaving property as not readable, I guess because there is an issue isX and reflection naming rules.


> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 03:22:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 17 Jun 2009 03:22:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7026) EJB3Deployer should
 use post processed metadata instead of merged metadata
In-Reply-To: <4292241.1245173576566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2088486.1245223377345.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai resolved JBAS-7026.
--------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


> EJB3Deployer should use post processed metadata instead of merged metadata
> --------------------------------------------------------------------------
>
>                 Key: JBAS-7026
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7026
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The EJB3Deployer currently uses merged metadata:
> addInput(MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME);
> This should be changed to use post processed metadata.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 03:23:59 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 17 Jun 2009 03:23:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-549) ConnectionTable:
 spurious Connection instances on concurrent connects
In-Reply-To: <10580511.1183710592881.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29148932.1245223439404.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Vladimir Blagojevic updated JGRP-549:
-------------------------------------

    Fix Version/s: 2.4.7
                       (was: 2.6)


Backported to 2.4 Branch. Affected files are ConnectionTable.java and BasicConnectionTable.java

> ConnectionTable: spurious Connection instances on concurrent connects
> ---------------------------------------------------------------------
>
>                 Key: JGRP-549
>                 URL: https://jira.jboss.org/jira/browse/JGRP-549
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.4.7
>
>
> If we have members A and B, and they don't yet have connections to each other, and start sending messages to each other at the exact same time, then we run into the following scenario:
> - A attempts to connect to B (new Socket())
> - B attempts to connect to A
> - A accepts B's connection and adds an entry for B into its table
> - B adds an entry for A into its table
> - B gets the accept() from A, but doesn't add the new Connection into its table because there is already a Connection. This leads to a spurious Connection object, which will only be closed and garbage collected once A or B leaves the cluster
> - We used to close Connections which were already in the table, but this lead to ping-pong effects where concurrent initial senders always closed each others connections
> - Even worse: a new Socket() always creates a new Connection object and places it into the table, *regardless* of whether a Connection for a given destination already exists or not !
> GOAL:
> #1 Have only 1 TCP connection between any 2 members
> #2 Establish a handshaking mechanism, to avoid spurious connections
> SOLUTION:
> - When A establishes a connection to B, A needs to get agreement from B first (and vice versa)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 03:25:56 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 17 Jun 2009 03:25:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-549) ConnectionTable:
 spurious Connection instances on concurrent connects
In-Reply-To: <10580511.1183710592881.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9643009.1245223556434.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Vladimir Blagojevic updated JGRP-549:
-------------------------------------

    Fix Version/s: 2.6


> ConnectionTable: spurious Connection instances on concurrent connects
> ---------------------------------------------------------------------
>
>                 Key: JGRP-549
>                 URL: https://jira.jboss.org/jira/browse/JGRP-549
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6
>
>
> If we have members A and B, and they don't yet have connections to each other, and start sending messages to each other at the exact same time, then we run into the following scenario:
> - A attempts to connect to B (new Socket())
> - B attempts to connect to A
> - A accepts B's connection and adds an entry for B into its table
> - B adds an entry for A into its table
> - B gets the accept() from A, but doesn't add the new Connection into its table because there is already a Connection. This leads to a spurious Connection object, which will only be closed and garbage collected once A or B leaves the cluster
> - We used to close Connections which were already in the table, but this lead to ping-pong effects where concurrent initial senders always closed each others connections
> - Even worse: a new Socket() always creates a new Connection object and places it into the table, *regardless* of whether a Connection for a given destination already exists or not !
> GOAL:
> #1 Have only 1 TCP connection between any 2 members
> #2 Establish a handshaking mechanism, to avoid spurious connections
> SOLUTION:
> - When A establishes a connection to B, A needs to get agreement from B first (and vice versa)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 03:37:56 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 17 Jun 2009 03:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Admin Join problem
 -GMS flush by coordinator failed
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31724581.1245224276777.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Vladimir Blagojevic commented on JGRP-985:
------------------------------------------

Ronn, I am not sure if this is fixed on 2.6 branch. This test scenario is also a bit unusual and hard to reproduce - having three nodes fail at the same time. I wonder if there is a way to trigger a scenario. I believe when you say that this lookup happens and I think the reason is that the view in coordinator gets corrupted somehow so that flush can never succeed and thus no new member can ever join. 

> Admin  Join problem -GMS flush by coordinator failed
> ----------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 04:56:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 17 Jun 2009 04:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6784) Add support for JMS
 ServerPeer
 managed object to support enabling metric collection through the console
In-Reply-To: <4119905.1239740302404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2337058.1245229016949.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-6784.
---------------------------------

    Resolution: Done


There is a "jboss.messaging:service=ServerPeer" component of type ComponentType("JMS", "ServerPeer")

   public void testServerPeer() throws Exception
   {
      ManagementView mgtView = getManagementView();
      ComponentType type = new ComponentType("JMS", "ServerPeer");
      ManagedComponent component = mgtView.getComponent("jboss.messaging:service=ServerPeer", type);
      assertNotNull(component);
      
      log.info("Properties: "+component.getProperties().keySet());
      
      ManagedOperation o = getOperation(component, "listMessageCountersAsHTML", new String[0]);
      MetaValue v = o.invoke(new MetaValue[0]);
      assertNotNull("null operation return value", v);
      log.debug("result" + v);
   }

> Add support for JMS ServerPeer managed object to support enabling metric collection through the console
> -------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6784
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6784
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Charles Crouch
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> See 
> https://jira.jboss.org/jira/browse/JBAS-6720?focusedCommentId=12461916#action_12461916
> https://jira.jboss.org/jira/browse/JBAS-6720?focusedCommentId=12461917#action_12461917
> for more info on why this would be a good thing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 05:05:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 17 Jun 2009 05:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6720) Make sure that the
 metrics for
 Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as
 ViewUse.STATISTIC
In-Reply-To: <7508166.1238615242987.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20835543.1245229556966.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-6720.
---------------------------------

    Resolution: Done


The ServerPeer managed object (name="jboss.messaging:service=ServerPeer", type=ComponentType("JMS", "ServerPeer")) exposes the enableMessageCounters property.

1182 [main] INFO org.jboss.test.profileservice.test.JmsDestinationUnitTestCase  - Properties: [defaultTopicJNDIContext, enableMessageCounters, providerVersion, postOffice, defaultExpiryQueue, suckerPassword, supportsFailover, JMSProviderName, clientAopConfig, serverAopConfig, JMSVersion, strictTck, providerMinorVersion, clusterPullConnectionFactoryName, defaultRedeliveryDelay, messageCounterSamplePeriod, defaultMessageCounterHistoryDayLimit, persistenceManager, messageStatistics, failoverCompleteTimeout, jmsUserManager, defaultQueueJNDIContext, messageCounters, serverPeerID, providerMajorVersion, version, failoverStartTimeout, useXAForMessagePull, JMSMajorVersion, recoverDeliveriesTimeout, JMSUserManager, defaultMaxDeliveryAttempts, JMSMinorVersion, defaultDLQ, securityDomain, defaultPreserveOrdering]


> Make sure that the metrics for Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as ViewUse.STATISTIC
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6720
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6720
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: JBoss AS Branch_5_x r86586, embjopr r266
> EmbJopr TS: testQueueMetrics
>            Reporter: Farah Juma
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Steps to reproduce:
> Create a new Topic or Queue using Embedded Jopr. Send some messages to the Topic or Queue. Navigate to the "Metrics" tab for the resource. The metrics do not get updated to reflect this change. All the values are 0.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 06:33:56 2009
From: jira-events at lists.jboss.org (Pavel Slavicek (JIRA))
Date: Wed, 17 Jun 2009 06:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7029) Test
 org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean
 fails on JDK6
Message-ID: <9161934.1245234836800.JavaMail.jira@cloud.prod.atl2.jboss.com>

Test org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean fails on JDK6
----------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7029
                 URL: https://jira.jboss.org/jira/browse/JBAS-7029
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: JBossAS-5.1.0.GA
         Environment: Windows and Linux 
JDK6
            Reporter: Pavel Slavicek
            Assignee: Shelly McGowan


Test org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean fails on JDK6 on line 

      Set<ManagedOperation> ops = mo.getOperations();
      log.debug(ops);
      assertEquals("Ops count is 8", 8, ops.size());

JDK6 contains JMX 1.4 and ThreadMXBean has 11 operations.

Test log:
junit.framework.AssertionFailedError: Ops count is 8 expected:&lt;8&gt; but was:&lt;11&gt;


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 06:41:56 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Wed, 17 Jun 2009 06:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7024) results of
 list*Messages methods
 of Queues and Topics have wrong meta type definition
In-Reply-To: <744707.1245166676454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24957738.1245235316590.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Lukas Krejci updated JBAS-7024:
-------------------------------

    Attachment: JBAS-7024.patch


I'm attaching a simple patch that fixed the issue for me.

> results of list*Messages methods of Queues and Topics have wrong meta type definition
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-7024
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7024
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBAPP_5_0 rev90256
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>            Priority: Critical
>         Attachments: JBAS-7024.patch
>
>
> The MessageListMapper used to define the meta types on list*Messages() methods for Queues and Topics advertises that the resulting type will be:
> CollectionMetaType[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> however the meta type of the actual meta values obtained using collectionValue.getElements() is advertised as:
> MapCompositeValue[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> This discrepancy is affecting the admin console, Jopr and JON because the meta values values have different type than the advertised meta type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 06:41:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 17 Jun 2009 06:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26456428.1245235316860.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

Bela

Here are my thoughts on this issue:

The problem
-----------
A user starts up jgroups, possibly specifying values for the some of the IP addresses which JGroups makes use of: 

* UDP: bind_addr, mcast_addr, diagnostics_addr 
* TCP: bind_addr, initial_hosts 

The user can specify zero or more such values, relying on defaults if values are left unspecified.

Possible Requirements
------------
1. We want to make sure that the complete set of values is specified, before any sockets are created. 
2. We assume that a mixed configuration of IPv4 and IPv6 addresses in one stack is unwanted. 
3. The decision to use a set of addresses must agree with the stacks available (or preferred in the case of dual stack availability) on the host.

Design for a solution (for UDP/TCP layers)
---------------------

Idea:
A. define defaults for all required IP address values above for both IPv4 and IPv6
B. at stack initialization, collect up all the values specified by the user (after parameters processing in UDP/TCP)
C. - if one or more values specified:
D.   - check if a consistent set of either IPv4 or IPv6 addresses
E.     - if not consistent set, raise exception and don't start stack
F.     - if consistent set, set useIPv4/useIPv6 variable to record the consistency, and complete the set with appropriate defaults

// NOTE: this takes the user's decision on IPv4 vs IPv6 and goes with it, making no checks to see if the 
// chosen stack is available on the machine. The user may receive Socket exceptions is the stack
// is not available, or if the stack preference (java.net.preferIPv4Stack) is set differently from the users choice
// on a dual stack machine. 
 
G. - if zero values specified: 
H.   - check to see which stacks are available on the machine (by enumerating all network interfaces and
     for each, checking if IPv4 or IPv6 addresses are defined) and set the values isIPv4Available/isIPv6Available
I.     - if only IPv4 is available, set useIPv4=true and complete the set of approproate defaults
J.     - if only IPv6 is available, set useIPv6=true and complete set of appropriate defaults
K.     - if both IPv6 and IPv4 are available, use JVM property java.net.preferIPv4Stack value to decide which stack to use
       and complete the set of appropriate defaults

// NOTE: this checks the presence of the IPv4 and IPv6 stacks, and chooses one, taking into account the JVM stack preference 
// setting. This determines uniquely whether IPv4 or IPv6 sockets will be created by the JVM. This may result in IPv4 addresses being
// used with IPv6 sockets (and so IPv4-mapped addresses used internally).

L. before sockets are created, we end up with the following values set:
     useIPv4/useIPv6, which indicates which IP stack was chosen, based on user specifying values (or not)
     isIPv4Available/isIPv6Available which indicates which stacks are available
     a complete consistent set of values for the IP addresses that JGroups needs

This design does not meet requirement 3 if the user specifies one or more values. That is, he could specify IPv6 addresses
when in fact the JVM has only an IPv4 stack available, or has a preference for an IPv4 stack. That could be changed by 
additionally checking if the consistent set of values specified by the user also is supported with a stack on the host (as is done in the case
where no values are specified). Don't know how involved you want JGroups to be in checking IP address configuratioin. This could be achieved for little extra cost
by checking stack availability before hand.    

With respect to probe.sh/Probe.java, I believe we need to also check what kind of stacks we have available in order to 
be able to multicast, without handling exceptions for stacks not being available. This would keep all the IP version
stuff separate from the general code. 

For the case of TCPPING and making defaults for initial_hosts consistent, could this be done within TCPPING when it 
received the LOCAL_ADDR and check consistency between LOCAL_ADDR and its initial hosts parameters? If the address
passed in by LOCAL_ADDR and the specified values for initial_hosts don't agree, then raise an exception and don't start the stack.
 
 


> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 06:50:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 17 Jun 2009 06:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16795634.1245235856544.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

Could add static functions to check stack availability to Util:

Util.isIPv4Available()
Util.isIPv6Available()



> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 07:12:56 2009
From: jira-events at lists.jboss.org (Stefan Anzinger (JIRA))
Date: Wed, 17 Jun 2009 07:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-993)
 InstanceNotFoundException when
 destroying jchannel (TP.ProtocolAdapter not found in MBean server)
Message-ID: <13853647.1245237176489.JavaMail.jira@cloud.prod.atl2.jboss.com>

InstanceNotFoundException when destroying jchannel (TP.ProtocolAdapter not found in MBean server)
-------------------------------------------------------------------------------------------------

                 Key: JGRP-993
                 URL: https://jira.jboss.org/jira/browse/JGRP-993
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.6.9
         Environment: Windows
            Reporter: Stefan Anzinger
            Assignee: Bela Ban
            Priority: Minor


When using shared transport with org.jgroups.jmx.JChannel there occurs a javax.management.InstanceNotFoundException when destroying the cannel.
It has no major impact as the exception is caught and not thrown outside of jgroups. Unfortunately the exception is logged as error where obviously is no error.

See the testcase and exception:

import java.io.ByteArrayInputStream;
import org.w3c.dom.*;
import javax.management.MBeanServer;
import javax.management.MBeanServerFactory;
import javax.xml.parsers.*;
import junit.framework.TestCase;


public class TestJGroups extends TestCase {
    /**
     * Tests the receiveLocalMessages feature on multiplex
     * channels.
     * 
     * <h2>Course of action</h2>
     * <ol>
     *   <li>Creates tow physical channels</li>
     *   <li>For each physical channel a mux channel is created</li>
     *   <li>Receive Local messages is turned off on the mux channels</li>
     *   <li>Local address has to be set manually after connecting the physical channels (This may be done automatically)</li>
     *   <li>Message is sent from the first mux to the second mux channel</li>
     * </ol>
     * 
     * @throws Exception
     */
    public void testSharedTransport() throws Exception
    {
        MBeanServer mbeanserver = MBeanServerFactory.createMBeanServer("testserver");
        org.jgroups.jmx.JChannel channel1 = new org.jgroups.jmx.JChannel();
        channel1.setClusterConfig(getConfig("singletonA"));
        channel1.setObjectName("test:service=Channel");
        channel1.create();
        channel1.setClusterName("Cluster1");
        channel1.start();
        channel1.stop();
        channel1.destroy();
        MBeanServerFactory.releaseMBeanServer(mbeanserver);
    }
    
    
    private Element getConfig(String singletonName) throws Exception {
        String config = 
            "<config>                                                                           " +
            "  <UDP mcast_recv_buf_size=\"80000\" mcast_send_buf_size=\"150000\"                " +
            "      mcast_port=\"32233\" mcast_addr=\"228.0.0.1\"                                " +
            "      ip_ttl=\"32\" singleton_name=\"" + singletonName + "\"/>                     " +
            "  <PING/>                                                                          " +
            "  <FD_SOCK/>                                                                       " +
            "  <VERIFY_SUSPECT timeout=\"15000\"/>                                              " +
            "  <pbcast.NAKACK gc_lag=\"50\" retransmit_timeout=\"300,600,1200,2400,48000\"/>    " +
            "  <UNICAST timeout=\"600,1200,2000,25000\"/>                                       " +
            "  <FRAG frag_size=\"8096\"/>                                                       " +
            "  <pbcast.STABLE desired_avg_gossip=\"20000\" max_bytes=\"500000\"/>               " +
            "  <pbcast.GMS print_local_addr=\"true\" join_timeout=\"60000\" shun=\"true\" />    " +
            "</config>                                                                          ";
        DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
        DocumentBuilder db = dbf.newDocumentBuilder();
        Document d = db.parse(new ByteArrayInputStream(config.getBytes()));
        return d.getDocumentElement();
    }

}


2009-06-17 13:05:49,409 [main] ERROR - org.jgroups.jmx.JmxConfigurator - failed to unregister test:service=Channel,protocol=TP.ProtocolAdapter
javax.management.InstanceNotFoundException: test:service=Channel,protocol=TP.ProtocolAdapter
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1010)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:354)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:527)
	at org.jgroups.jmx.JmxConfigurator.unregisterProtocols(JmxConfigurator.java:121)
	at org.jgroups.jmx.JChannel.destroy(JChannel.java:256)
	at com.j2fe.clustering.impl.TestJGroups.testSharedTransport(TestJGroups.java:41)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 07:16:56 2009
From: jira-events at lists.jboss.org (Stefan Anzinger (JIRA))
Date: Wed, 17 Jun 2009 07:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-993)
 InstanceNotFoundException when
 destroying jchannel (TP.ProtocolAdapter not found in MBean server)
In-Reply-To: <13853647.1245237176489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24226415.1245237416517.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Stefan Anzinger commented on JGRP-993:
--------------------------------------

I have pasted an invalid javadoc comment on this issue, here is the right one :-): 

    /**
     * Tests the shared transport inclusive the registering MBeans
     * channels.
     * 
     * <h2>Course of action</h2>
     * <ol>
     *   <li>Start MBean Server</li>
     *   <li>Create MBean JChannel (Registers protocols in MBean Server</li>
     *   <li>Start JChannel</li>
     *   <li>Stop JChannel</li>
     *   <li>Destroy JChannel (Removes all protocols from MBean Server, which gives exception that MBean for TP.ProtocolAdapter does not exist)</li>
     * </ol>
     * 
     * @throws Exception
     */

> InstanceNotFoundException when destroying jchannel (TP.ProtocolAdapter not found in MBean server)
> -------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-993
>                 URL: https://jira.jboss.org/jira/browse/JGRP-993
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.9
>         Environment: Windows
>            Reporter: Stefan Anzinger
>            Assignee: Bela Ban
>            Priority: Minor
>
> When using shared transport with org.jgroups.jmx.JChannel there occurs a javax.management.InstanceNotFoundException when destroying the cannel.
> It has no major impact as the exception is caught and not thrown outside of jgroups. Unfortunately the exception is logged as error where obviously is no error.
> See the testcase and exception:
> import java.io.ByteArrayInputStream;
> import org.w3c.dom.*;
> import javax.management.MBeanServer;
> import javax.management.MBeanServerFactory;
> import javax.xml.parsers.*;
> import junit.framework.TestCase;
> public class TestJGroups extends TestCase {
>     /**
>      * Tests the receiveLocalMessages feature on multiplex
>      * channels.
>      * 
>      * <h2>Course of action</h2>
>      * <ol>
>      *   <li>Creates tow physical channels</li>
>      *   <li>For each physical channel a mux channel is created</li>
>      *   <li>Receive Local messages is turned off on the mux channels</li>
>      *   <li>Local address has to be set manually after connecting the physical channels (This may be done automatically)</li>
>      *   <li>Message is sent from the first mux to the second mux channel</li>
>      * </ol>
>      * 
>      * @throws Exception
>      */
>     public void testSharedTransport() throws Exception
>     {
>         MBeanServer mbeanserver = MBeanServerFactory.createMBeanServer("testserver");
>         org.jgroups.jmx.JChannel channel1 = new org.jgroups.jmx.JChannel();
>         channel1.setClusterConfig(getConfig("singletonA"));
>         channel1.setObjectName("test:service=Channel");
>         channel1.create();
>         channel1.setClusterName("Cluster1");
>         channel1.start();
>         channel1.stop();
>         channel1.destroy();
>         MBeanServerFactory.releaseMBeanServer(mbeanserver);
>     }
>     
>     
>     private Element getConfig(String singletonName) throws Exception {
>         String config = 
>             "<config>                                                                           " +
>             "  <UDP mcast_recv_buf_size=\"80000\" mcast_send_buf_size=\"150000\"                " +
>             "      mcast_port=\"32233\" mcast_addr=\"228.0.0.1\"                                " +
>             "      ip_ttl=\"32\" singleton_name=\"" + singletonName + "\"/>                     " +
>             "  <PING/>                                                                          " +
>             "  <FD_SOCK/>                                                                       " +
>             "  <VERIFY_SUSPECT timeout=\"15000\"/>                                              " +
>             "  <pbcast.NAKACK gc_lag=\"50\" retransmit_timeout=\"300,600,1200,2400,48000\"/>    " +
>             "  <UNICAST timeout=\"600,1200,2000,25000\"/>                                       " +
>             "  <FRAG frag_size=\"8096\"/>                                                       " +
>             "  <pbcast.STABLE desired_avg_gossip=\"20000\" max_bytes=\"500000\"/>               " +
>             "  <pbcast.GMS print_local_addr=\"true\" join_timeout=\"60000\" shun=\"true\" />    " +
>             "</config>                                                                          ";
>         DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
>         DocumentBuilder db = dbf.newDocumentBuilder();
>         Document d = db.parse(new ByteArrayInputStream(config.getBytes()));
>         return d.getDocumentElement();
>     }
> }
> 2009-06-17 13:05:49,409 [main] ERROR - org.jgroups.jmx.JmxConfigurator - failed to unregister test:service=Channel,protocol=TP.ProtocolAdapter
> javax.management.InstanceNotFoundException: test:service=Channel,protocol=TP.ProtocolAdapter
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1010)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:354)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:527)
> 	at org.jgroups.jmx.JmxConfigurator.unregisterProtocols(JmxConfigurator.java:121)
> 	at org.jgroups.jmx.JChannel.destroy(JChannel.java:256)
> 	at com.j2fe.clustering.impl.TestJGroups.testSharedTransport(TestJGroups.java:41)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at junit.framework.TestCase.runTest(TestCase.java:154)
> 	at junit.framework.TestCase.runBare(TestCase.java:127)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 07:20:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 17 Jun 2009 07:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-993)
 InstanceNotFoundException when
 destroying jchannel (TP.ProtocolAdapter not found in MBean server)
In-Reply-To: <13853647.1245237176489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12933230.1245237656698.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban commented on JGRP-993:
-------------------------------

org.jgroups.jmx.JChannel has been deprecated, try this with org.jgroups.JChannel instead !

> InstanceNotFoundException when destroying jchannel (TP.ProtocolAdapter not found in MBean server)
> -------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-993
>                 URL: https://jira.jboss.org/jira/browse/JGRP-993
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.9
>         Environment: Windows
>            Reporter: Stefan Anzinger
>            Assignee: Bela Ban
>            Priority: Minor
>
> When using shared transport with org.jgroups.jmx.JChannel there occurs a javax.management.InstanceNotFoundException when destroying the cannel.
> It has no major impact as the exception is caught and not thrown outside of jgroups. Unfortunately the exception is logged as error where obviously is no error.
> See the testcase and exception:
> import java.io.ByteArrayInputStream;
> import org.w3c.dom.*;
> import javax.management.MBeanServer;
> import javax.management.MBeanServerFactory;
> import javax.xml.parsers.*;
> import junit.framework.TestCase;
> public class TestJGroups extends TestCase {
>     /**
>      * Tests the receiveLocalMessages feature on multiplex
>      * channels.
>      * 
>      * <h2>Course of action</h2>
>      * <ol>
>      *   <li>Creates tow physical channels</li>
>      *   <li>For each physical channel a mux channel is created</li>
>      *   <li>Receive Local messages is turned off on the mux channels</li>
>      *   <li>Local address has to be set manually after connecting the physical channels (This may be done automatically)</li>
>      *   <li>Message is sent from the first mux to the second mux channel</li>
>      * </ol>
>      * 
>      * @throws Exception
>      */
>     public void testSharedTransport() throws Exception
>     {
>         MBeanServer mbeanserver = MBeanServerFactory.createMBeanServer("testserver");
>         org.jgroups.jmx.JChannel channel1 = new org.jgroups.jmx.JChannel();
>         channel1.setClusterConfig(getConfig("singletonA"));
>         channel1.setObjectName("test:service=Channel");
>         channel1.create();
>         channel1.setClusterName("Cluster1");
>         channel1.start();
>         channel1.stop();
>         channel1.destroy();
>         MBeanServerFactory.releaseMBeanServer(mbeanserver);
>     }
>     
>     
>     private Element getConfig(String singletonName) throws Exception {
>         String config = 
>             "<config>                                                                           " +
>             "  <UDP mcast_recv_buf_size=\"80000\" mcast_send_buf_size=\"150000\"                " +
>             "      mcast_port=\"32233\" mcast_addr=\"228.0.0.1\"                                " +
>             "      ip_ttl=\"32\" singleton_name=\"" + singletonName + "\"/>                     " +
>             "  <PING/>                                                                          " +
>             "  <FD_SOCK/>                                                                       " +
>             "  <VERIFY_SUSPECT timeout=\"15000\"/>                                              " +
>             "  <pbcast.NAKACK gc_lag=\"50\" retransmit_timeout=\"300,600,1200,2400,48000\"/>    " +
>             "  <UNICAST timeout=\"600,1200,2000,25000\"/>                                       " +
>             "  <FRAG frag_size=\"8096\"/>                                                       " +
>             "  <pbcast.STABLE desired_avg_gossip=\"20000\" max_bytes=\"500000\"/>               " +
>             "  <pbcast.GMS print_local_addr=\"true\" join_timeout=\"60000\" shun=\"true\" />    " +
>             "</config>                                                                          ";
>         DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
>         DocumentBuilder db = dbf.newDocumentBuilder();
>         Document d = db.parse(new ByteArrayInputStream(config.getBytes()));
>         return d.getDocumentElement();
>     }
> }
> 2009-06-17 13:05:49,409 [main] ERROR - org.jgroups.jmx.JmxConfigurator - failed to unregister test:service=Channel,protocol=TP.ProtocolAdapter
> javax.management.InstanceNotFoundException: test:service=Channel,protocol=TP.ProtocolAdapter
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1010)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:354)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:527)
> 	at org.jgroups.jmx.JmxConfigurator.unregisterProtocols(JmxConfigurator.java:121)
> 	at org.jgroups.jmx.JChannel.destroy(JChannel.java:256)
> 	at com.j2fe.clustering.impl.TestJGroups.testSharedTransport(TestJGroups.java:41)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at junit.framework.TestCase.runTest(TestCase.java:154)
> 	at junit.framework.TestCase.runBare(TestCase.java:127)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 07:33:08 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 17 Jun 2009 07:33:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-969) TestNG: enable
 OverlappingMergeTest.testOverlappingMergeWithABC()
In-Reply-To: <2800475.1241011008031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23630165.1245238388715.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban resolved JGRP-969.
---------------------------

    Resolution: Done


> TestNG: enable OverlappingMergeTest.testOverlappingMergeWithABC()
> -----------------------------------------------------------------
>
>                 Key: JGRP-969
>                 URL: https://jira.jboss.org/jira/browse/JGRP-969
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> This test is currently disabled as it depends on MERGE4

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 07:53:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 17 Jun 2009 07:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1653) specify the
 management attribute as lower-cased in management messages
In-Reply-To: <2107452.1244817716743.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33350873.1245239636523.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil closed JBMESSAGING-1653.
------------------------------------

    Resolution: Done
      Assignee: Jeff Mesnil  (was: Tim Fox)


fixed in the trunk

> specify the management attribute as lower-cased in management messages
> ----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1653
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1653
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> to be more consistent with Java conventions, the user should be able to specify management attribute lower-cased when sending
> management message with ManagementHelper.putAttribute() method.
> E.g. to retrieve the value of the QueueContrlol's messageCount, the user will call ManagementHelper.putAttribute(msg, res, "messageCount") and no longer  ManagementHelper.putAttribute(msg, res, "MessageCount")

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 07:53:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 17 Jun 2009 07:53:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5691538.1245239637033.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1657:
-----------------------------------------

The test does not always fail, sometimes it is ok.
My observation:

1. client connects to node1, whenever a consumer is created, node1 will tell node2 to do something (in case of topic, node2 will add a binding accordingly). whenever a consumer is closed, node1 will tell node2 to remove the binding. This is achieved through jgroups.

2. when node1 is killed, client failover to node 2 and continue the operation. node2 will get notification of node1's death and do server side failover.
if client requests come in after node1's death but before node2 get notified, node2 still keeps the node1 in its cluster view, so it will try to tell node1 and expect response. But in fact node1 is already dead, so it will throw the exception.

3. actually if we kill node2, there is still a chance to get the same error. 

I'll try to figure out how to fix it and update soon.


> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 08:58:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 17 Jun 2009 08:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21900304.1245243536677.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

I'm starting to look at the details of the implementation. There are three cvs repos I cound with 2.8 associated with them:

HEAD -> 2.8.Beta1
Branch_JGroups_2_8_LogicalAddresses
Branch_2_8_temp

which one should changes be applied to? I assume HEAD?





> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 09:19:56 2009
From: jira-events at lists.jboss.org (Emanuele Fabbri (JIRA))
Date: Wed, 17 Jun 2009 09:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-354) jPDL - element "main"
 is not known in the jpdl-4.0.xsd schema
Message-ID: <13366315.1245244796998.JavaMail.jira@cloud.prod.atl2.jboss.com>

jPDL - element "main" is not known in the jpdl-4.0.xsd schema
-------------------------------------------------------------

                 Key: GPD-354
                 URL: https://jira.jboss.org/jira/browse/GPD-354
             Project: JBoss jBPM GPD
          Issue Type: Patch
          Components: jpdl
    Affects Versions: jBPM jPDL Designer 4.0.0.CR1
         Environment: Eclipse Ganymede 3.4.2 Build id: M20090211-1700
            Reporter: Emanuele Fabbri
            Assignee: Koen Aers


If I try to validate my jPDL with the schema that I get from the latest release of jBPM (4.0CR1) Eclipse return an error about the "mail" element.

This kind of element is also not availble by the Eclipse plug-in.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 09:27:56 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 17 Jun 2009 09:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7030) Avoid unnecessary
 class scanning for annotations during startup
Message-ID: <6125412.1245245276439.JavaMail.jira@cloud.prod.atl2.jboss.com>

Avoid unnecessary class scanning for annotations during startup
---------------------------------------------------------------

                 Key: JBAS-7030
                 URL: https://jira.jboss.org/jira/browse/JBAS-7030
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Deployers
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Scott Marlow
            Assignee: Scott Marlow
            Priority: Minor
             Fix For: JBossAS-6.0.0.Alpha1


There are a few things that we can do to avoid unnecessary scanning of classes for annotations.  This Jira is about exploring our options and making the changes that make sense.  

More context is in email thread http://lists.jboss.org/pipermail/jboss-development/2009-June/014537.html



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 09:46:56 2009
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Wed, 17 Jun 2009 09:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31175118.1245246416581.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Justin Bertram commented on JBMESSAGING-1657:
---------------------------------------------

I have also seen the test succeed on occasion.  This is definitely an issue of timing.  The shorter the "sleep" in the client the more easy the problem is to produce.

> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 10:18:07 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 17 Jun 2009 10:18:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7018) Upgrade EJB3 to
	1.1.7
In-Reply-To: <25050850.1245054836512.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21476565.1245248287967.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai resolved JBAS-7018.
--------------------------------

    Resolution: Done


Tested against a local hudson run. No regressions. 

Done in r90332.


> Upgrade EJB3 to 1.1.7
> ---------------------
>
>                 Key: JBAS-7018
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7018
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Update the AS to use the newly released EJB3 1.1.7 version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 10:18:07 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 17 Jun 2009 10:18:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-193) Provide a
 extended
 DeploymentVisitor which can be used for filtering out deployers
In-Reply-To: <10118475.1245157136971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27831389.1245248287829.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai resolved JBDEPLOY-193.
-----------------------------------

    Fix Version/s:  JBDEPLOY-2.2.x
       Resolution: Done


http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-spi/src/main/java/org/jboss/deployers/spi/deployer/helpers/ExtendedDeploymentVisitor.java is now available and can be used when the deployer knows the attachment name and type it is interested within an unit.

> Provide a extended DeploymentVisitor which can be used for filtering out deployers
> ----------------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-193
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-193
>             Project: JBoss Deployers
>          Issue Type: Feature Request
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For:  JBDEPLOY-2.2.x
>
>
> The AbstractRealDeployerWithInput currently relies on a DeploymentVisitor for filtering out deployers while processing out a deployment unit. The DeploymentVisitor is responsible for specifying the "type" of attachment to  look for, in the unit, to decide whether the unit can be processed by the deployer. There are 2 short-comings with the current DeploymentVisitor:
> 1) A unit can have multiple attachments of the same type - This effectively means a deployer cannot specify which out of these n attachments, is it interested in. This results in the deployer being called multiple times for the same unit.
> 2) Because the AbstractRealDeployerWithInput relies on the type of the attachment, it is expensive:
> protected <U> void deploy(DeploymentUnit unit, DeploymentVisitor<U> visitor) throws DeploymentException
>    {
>       if (visitor == null)
>          throw new IllegalArgumentException("Null visitor.");
>       List<U> visited = new ArrayList<U>();
>       try
>       {
>          Set<? extends U> deployments = unit.getAllMetaData(visitor.getVisitorType());
> ...
> unit.getAllMetaData internally iterates over all attachments to create collection of eligible attachments.
> To improve this, an ExtendedDeploymentVisitor can be introduced which allows for a deployer to register itself for a specific attachment with name and the corresponding type of the attachment. A new deployer can then use this ExtendedDeploymentVisitor to efficiently process the deployment unit.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 10:29:08 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 17 Jun 2009 10:29:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-6777) 'interleaving' prop
 on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33031737.1245248948609.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer reopened JBAS-6777:
--------------------------------



Using the EAP branch r90329, I'm still seeing the interleaving prop always having a value of false, for new ds.xml files that contain the interleaving element, as well as after I've updated the prop's value to true via the Profile Service. Did you forget to check the fix into the EAP branch?


> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:03:56 2009
From: jira-events at lists.jboss.org (Marek Posolda (JIRA))
Date: Wed, 17 Jun 2009 11:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2424) Exception while
 calling removePublicRenderParameter on javax.portlet.actionResponse
In-Reply-To: <21497204.1245251036629.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23236751.1245251036969.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Marek Posolda updated JBPORTAL-2424:
------------------------------------

    Attachment: coordination-exception.png


> Exception while calling removePublicRenderParameter on javax.portlet.actionResponse
> -----------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2424
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2424
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.7.3 Final
>         Environment: Ubuntu linux,
> Sun Java 1.5.0_16,
> JBoss 4.3.2.GA with JBoss Portal 2.7.2 - branch
>            Reporter: Marek Posolda
>         Attachments: coordination-exception.png
>
>
> Calling of method removePublicRenderParameter on javax.portlet.ActionResponse doesn't work correctly if you try to call method on some previously saved parameter. Problem can be easily simulated by trying this scenario (portal-coordination-samples should be deployed):
> 1) Go to http://localhost:8080/portal/portal/default/Coordination+Samples/Parameters+-+Implicit
> 2) Add value "Some value" to parameter "daa1" in PublicParametersPortletWindow1. Click to "Update" button.
> 3) Click to the text field "daa1" and delete the value "Some value" (not click to "Remove" link but delete the value directly in text field). Click to "Update" button.
> 4) You can see Tomcat page with 500 code. Screenshot with exception attached. This exception on it:
> java.lang.IllegalArgumentException: Array must not be zero length
>   org.jboss.portal.common.util.ParameterMap$ValueConverter.getInternal(ParameterMap.java:431)
>   org.jboss.portal.common.util.ParameterMap$ValueConverter.getInternal(ParameterMap.java:406)
>   org.jboss.portal.common.util.AbstractTypedMap$Converter$4.transform(AbstractTypedMap.java:137)
>   org.jboss.portal.common.util.AbstractTypedMap.put(AbstractTypedMap.java:239)
>   org.jboss.portal.common.util.ParameterMap.setValues(ParameterMap.java:245)
>   org.jboss.portal.core.portlet.PortletRequestEncoder.configure(PortletRequestEncoder.java:208)
>   org.jboss.portal.core.portlet.PortletRequestEncoder.encodeRender(PortletRequestEncoder.java:169)
>   org.jboss.portal.core.model.portal.PortalObjectURLFactory.doMapping(PortalObjectURLFactory.java:168)
>   org.jboss.portal.core.controller.command.mapper.DelegatingURLFactoryService.doMapping(DelegatingURLFactoryService.java:68)
>   org.jboss.portal.core.controller.ControllerContext.renderURL(ControllerContext.java:171)
>   org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:62)
>   org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:70)
>   org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:315)
>   org.jboss.portal.core.controller.Controller.processCommand(Controller.java:303)
>    org.jboss.portal.core.controller.Controller.handle(Controller.java:261)
>   org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
>   org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:68)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.PortalContextPathInterceptor.invoke(PortalContextPathInterceptor.java:45)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:196)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.server.aspects.server.SignOutInterceptor.invoke(SignOutInterceptor.java:98)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.IdentityCacheInterceptor.invoke(IdentityCacheInterceptor.java:68)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>    org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>   org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>    org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>   org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:69)
>   org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:130)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
>   org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:252)
>    javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>   org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:03:56 2009
From: jira-events at lists.jboss.org (Marek Posolda (JIRA))
Date: Wed, 17 Jun 2009 11:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2424) Exception while
 calling removePublicRenderParameter on javax.portlet.actionResponse
Message-ID: <21497204.1245251036629.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exception while calling removePublicRenderParameter on javax.portlet.actionResponse
-----------------------------------------------------------------------------------

                 Key: JBPORTAL-2424
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2424
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.7.3 Final
         Environment: Ubuntu linux,
Sun Java 1.5.0_16,
JBoss 4.3.2.GA with JBoss Portal 2.7.2 - branch
            Reporter: Marek Posolda
         Attachments: coordination-exception.png

Calling of method removePublicRenderParameter on javax.portlet.ActionResponse doesn't work correctly if you try to call method on some previously saved parameter. Problem can be easily simulated by trying this scenario (portal-coordination-samples should be deployed):

1) Go to http://localhost:8080/portal/portal/default/Coordination+Samples/Parameters+-+Implicit

2) Add value "Some value" to parameter "daa1" in PublicParametersPortletWindow1. Click to "Update" button.

3) Click to the text field "daa1" and delete the value "Some value" (not click to "Remove" link but delete the value directly in text field). Click to "Update" button.

4) You can see Tomcat page with 500 code. Screenshot with exception attached. This exception on it:

java.lang.IllegalArgumentException: Array must not be zero length
  org.jboss.portal.common.util.ParameterMap$ValueConverter.getInternal(ParameterMap.java:431)
  org.jboss.portal.common.util.ParameterMap$ValueConverter.getInternal(ParameterMap.java:406)
  org.jboss.portal.common.util.AbstractTypedMap$Converter$4.transform(AbstractTypedMap.java:137)
  org.jboss.portal.common.util.AbstractTypedMap.put(AbstractTypedMap.java:239)
  org.jboss.portal.common.util.ParameterMap.setValues(ParameterMap.java:245)
  org.jboss.portal.core.portlet.PortletRequestEncoder.configure(PortletRequestEncoder.java:208)
  org.jboss.portal.core.portlet.PortletRequestEncoder.encodeRender(PortletRequestEncoder.java:169)
  org.jboss.portal.core.model.portal.PortalObjectURLFactory.doMapping(PortalObjectURLFactory.java:168)
  org.jboss.portal.core.controller.command.mapper.DelegatingURLFactoryService.doMapping(DelegatingURLFactoryService.java:68)
  org.jboss.portal.core.controller.ControllerContext.renderURL(ControllerContext.java:171)
  org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:62)
  org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:70)
  org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:315)
  org.jboss.portal.core.controller.Controller.processCommand(Controller.java:303)
   org.jboss.portal.core.controller.Controller.handle(Controller.java:261)
  org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
  org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:68)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.core.aspects.server.PortalContextPathInterceptor.invoke(PortalContextPathInterceptor.java:45)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:196)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.server.aspects.server.SignOutInterceptor.invoke(SignOutInterceptor.java:98)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.core.aspects.server.IdentityCacheInterceptor.invoke(IdentityCacheInterceptor.java:68)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
  org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
   org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
  org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
  org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
   org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
  org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
  org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
  org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:69)
  org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:130)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
  org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:252)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
  org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:14:08 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 17 Jun 2009 11:14:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7024) results of
 list*Messages methods
 of Queues and Topics have wrong meta type definition
In-Reply-To: <744707.1245166676454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15557087.1245251648174.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark reassigned JBAS-7024:
-----------------------------------

    Assignee: Scott M Stark  (was: Jason T. Greene)


> results of list*Messages methods of Queues and Topics have wrong meta type definition
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-7024
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7024
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBAPP_5_0 rev90256
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Critical
>         Attachments: JBAS-7024.patch
>
>
> The MessageListMapper used to define the meta types on list*Messages() methods for Queues and Topics advertises that the resulting type will be:
> CollectionMetaType[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> however the meta type of the actual meta values obtained using collectionValue.getElements() is advertised as:
> MapCompositeValue[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> This discrepancy is affecting the admin console, Jopr and JON because the meta values values have different type than the advertised meta type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:23:57 2009
From: jira-events at lists.jboss.org (Andy Goldstein (JIRA))
Date: Wed, 17 Jun 2009 11:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24040960.1245252237187.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andy Goldstein commented on JBMESSAGING-1657:
---------------------------------------------

FYI this is not limited to co-located JBoss Messaging servers & JMS client.  We've had this happen when JBoss Messaging was on 1 machine, and the client was on another machine.

Our test case was slightly different from Justin's (which aligns with #3 above):
 -Start test client connecting to node2
 -Observe client log filling up with "." 
 -Drop JBoss running on node1 (using kill -9 <pid>) 
 -Client fails with org.jboss.jms.exception.MessagingJMSException
 -Observe java.lang.IllegalStateException on node2

The difference is we had our JmsTest client connecting to the 2nd server instead of the 1st.  So the test client was always trying to connect to node2, and when we killed node1, the next attempt by the client to connect to node2 that immediately followed node1's death failed (presumably for the reason stated in #2 above).

> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:30:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 17 Jun 2009 11:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-994) JChannel: remove
 AUTO_RECONNECT and AUTO_GETSTATE options
Message-ID: <3749488.1245252656461.JavaMail.jira@cloud.prod.atl2.jboss.com>

JChannel: remove AUTO_RECONNECT and AUTO_GETSTATE options
---------------------------------------------------------

                 Key: JGRP-994
                 URL: https://jira.jboss.org/jira/browse/JGRP-994
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.0




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:30:56 2009
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Wed, 17 Jun 2009 11:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2424) Exception while
 calling removePublicRenderParameter on javax.portlet.actionResponse
In-Reply-To: <21497204.1245251036629.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10945856.1245252656752.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Prabhat Jha updated JBPORTAL-2424:
----------------------------------

        Fix Version/s: 2.7.3 Final
    Affects Version/s: 2.7.2 Final
                           (was: 2.7.3 Final)


> Exception while calling removePublicRenderParameter on javax.portlet.actionResponse
> -----------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2424
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2424
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.7.2 Final
>         Environment: Ubuntu linux,
> Sun Java 1.5.0_16,
> JBoss 4.3.2.GA with JBoss Portal 2.7.2 - branch
>            Reporter: Marek Posolda
>             Fix For: 2.7.3 Final
>
>         Attachments: coordination-exception.png
>
>
> Calling of method removePublicRenderParameter on javax.portlet.ActionResponse doesn't work correctly if you try to call method on some previously saved parameter. Problem can be easily simulated by trying this scenario (portal-coordination-samples should be deployed):
> 1) Go to http://localhost:8080/portal/portal/default/Coordination+Samples/Parameters+-+Implicit
> 2) Add value "Some value" to parameter "daa1" in PublicParametersPortletWindow1. Click to "Update" button.
> 3) Click to the text field "daa1" and delete the value "Some value" (not click to "Remove" link but delete the value directly in text field). Click to "Update" button.
> 4) You can see Tomcat page with 500 code. Screenshot with exception attached. This exception on it:
> java.lang.IllegalArgumentException: Array must not be zero length
>   org.jboss.portal.common.util.ParameterMap$ValueConverter.getInternal(ParameterMap.java:431)
>   org.jboss.portal.common.util.ParameterMap$ValueConverter.getInternal(ParameterMap.java:406)
>   org.jboss.portal.common.util.AbstractTypedMap$Converter$4.transform(AbstractTypedMap.java:137)
>   org.jboss.portal.common.util.AbstractTypedMap.put(AbstractTypedMap.java:239)
>   org.jboss.portal.common.util.ParameterMap.setValues(ParameterMap.java:245)
>   org.jboss.portal.core.portlet.PortletRequestEncoder.configure(PortletRequestEncoder.java:208)
>   org.jboss.portal.core.portlet.PortletRequestEncoder.encodeRender(PortletRequestEncoder.java:169)
>   org.jboss.portal.core.model.portal.PortalObjectURLFactory.doMapping(PortalObjectURLFactory.java:168)
>   org.jboss.portal.core.controller.command.mapper.DelegatingURLFactoryService.doMapping(DelegatingURLFactoryService.java:68)
>   org.jboss.portal.core.controller.ControllerContext.renderURL(ControllerContext.java:171)
>   org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:62)
>   org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:70)
>   org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:315)
>   org.jboss.portal.core.controller.Controller.processCommand(Controller.java:303)
>    org.jboss.portal.core.controller.Controller.handle(Controller.java:261)
>   org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
>   org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:68)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.PortalContextPathInterceptor.invoke(PortalContextPathInterceptor.java:45)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:196)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.server.aspects.server.SignOutInterceptor.invoke(SignOutInterceptor.java:98)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.IdentityCacheInterceptor.invoke(IdentityCacheInterceptor.java:68)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>    org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>   org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>    org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>   org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:69)
>   org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:130)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
>   org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:252)
>    javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>   org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:32:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 17 Jun 2009 11:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11755311.1245252776558.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-142:
-------------------------------

    Attachment:     (was: jbweb-142.patch)


> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:34:57 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 17 Jun 2009 11:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6461596.1245252897121.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-142:
-------------------------------

    Attachment: jbweb-142.patch


Revised patch:
1) Removed extraneous space in constant name.
2) Changed constant name to org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE

> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-142.patch
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:34:56 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Wed, 17 Jun 2009 11:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26763950.1245252896843.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andy Taylor reopened JBMESSAGING-1646:
--------------------------------------



This has been reported as still happening

> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>         Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>             Fix For: 2.0.0.beta2
>
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:42:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 11:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-278)
 JaasSecurityManager should not
 "swallow" LoginExceptions thrown by LoginModules
In-Reply-To: <10908665.1223380580859.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32800059.1245253376842.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated SECURITY-278:
-----------------------------------

    Fix Version/s: 2.0.4.GA


> JaasSecurityManager should not "swallow" LoginExceptions thrown by LoginModules
> -------------------------------------------------------------------------------
>
>                 Key: SECURITY-278
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-278
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.2.GA
>         Environment: JBoss AS 4.2.2.GA
>            Reporter: egor kolesnikov
>            Assignee: Anil Saldhana
>             Fix For: 2.0.4.GA
>
>
> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/jboss/src/main/org/jboss/security/plugins/JaasSecurityManager.java?annotate=1091&pathrev=1091
> JaasSecurityManager.authenticate(String beanName, Principal principal, Object credential) has the following block:
> try {
> // call login modules and authenticate
>  } catch (Exception ex) {
>     ex.printStackTrace();
>     return false;
> }
> Disregarding the fact that "ex.printStackTrace()" is a definitely bad code style, swallowing all exceptions violates the JAAS specifications regarding the fact that login modules could return false or throw LoginException if login attempt has failed (see http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/spi/LoginModule.html for details). This also affects Jboss SEAM framework which raises special event if LoginException has been thrown.
> Observed behavior:
> When LoginModule throws LoginException, JaasSecurityManager.authenticate() returns false without any additional checks.
> Expected behavior:
> When LoginModule throws LoginException, JaasSecurityManager should not catch (or should at least re-throw) it and allow the exception to reach the client code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:42:57 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 17 Jun 2009 11:42:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8127204.1245253377141.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson commented on JBWEB-142:
------------------------------------

Please apply upstream to trunk and the 2.1.x branch. I will apply to the CP branch under the linked CP Jira.

> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-142.patch
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:44:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 11:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-339) ClientLoginModule
 improperly handles SecurityAssociation stack in abort()
In-Reply-To: <7186620.1228596936975.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25913075.1245253496771.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated SECURITY-339:
-----------------------------------

      Component/s: JBossSX
    Fix Version/s: JBossSecurity_2.0.4


> ClientLoginModule improperly handles SecurityAssociation stack in abort()
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-339
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-339
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Marco Schulze
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.4
>
>
> The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the corresponding push happens in commit() [via SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)]. That means, whenever a login fails, the commit is not called (thus nothing pushed), but the abort pops out an element from the stack. This should not be done. IMHO the abort() method should look like this:
>   public boolean abort() throws LoginException
>    {
>       if( trace )
>          log.trace("abort");
>       if( restoreLoginIdentity == false )
>       {
>          // Clear the entire security association stack
>          SecurityAssociationActions.clear();         
>       }
>       return true;
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:47:07 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 11:47:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-256) Optimization:
 Precreate authorization modules in the JBossAuthorizationManager
In-Reply-To: <31000899.1214942971784.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17136609.1245253627148.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated SECURITY-256:
-----------------------------------

    Fix Version/s: JBossSecurity_2.0.4
                       (was: 2.0.3.Beta1)


> Optimization: Precreate authorization modules in the JBossAuthorizationManager
> ------------------------------------------------------------------------------
>
>                 Key: SECURITY-256
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-256
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.2.CR6
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.4
>
>
> The JBossAuthorizationManager should have initialization steps to precreate the authorization modules if the configuration is available for the security domain.  There needs to be an external mechanism to clear the authorization modules.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:48:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 11:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-255)
 IdentityLoginModule Incomplete
 password-stacking useFirstPass implementation
In-Reply-To: <4221409.1214820452243.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16075556.1245253736656.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated SECURITY-255:
-----------------------------------

    Fix Version/s: JBossSecurity_2.0.4
                       (was: 2.0.3.Beta2)
         Assignee: Anil Saldhana  (was: Darran Lofthouse)


> IdentityLoginModule Incomplete password-stacking useFirstPass implementation
> ----------------------------------------------------------------------------
>
>                 Key: SECURITY-255
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-255
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.2.CR6
>            Reporter: Darran Lofthouse
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.4
>
>
> The IdentityLoginModule has got an incomplete useFirstPass implementation.
> The login() method does start with: -
>   if( super.login() == true )
>          return true;
> To skip login if useFirstPass is set and authentication has already occurred.
> However at the end of login() setting the principal in the shared state map should only happen if useFirstPass was set.  
> Also for this to work a credential also needs to be stored in the sharedStateMap otherwise other modules will assume authentication has not occurred.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:48:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 11:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-101)
 JBossAuthorizationManager needs to use cache to speed up
In-Reply-To: <13553682.1197617811738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12921128.1245253736819.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated SECURITY-101:
-----------------------------------

    Fix Version/s:     (was: 2.0.3.Beta2)


> JBossAuthorizationManager needs to use cache to speed up
> --------------------------------------------------------
>
>                 Key: SECURITY-101
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-101
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.2-BETA
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>
> There is a need for a CachePolicy.  Methods like getCurrentRoles() need to speed up a bit.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:03:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 17 Jun 2009 12:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7031) make JMX invoker,
 jmx-console, 
 admin-console, and remote access to Profile Service all use the same
 security domain
Message-ID: <112800.1245254636508.JavaMail.jira@cloud.prod.atl2.jboss.com>

make JMX invoker, jmx-console, admin-console, and remote access to Profile Service all use the same security domain
-------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7031
                 URL: https://jira.jboss.org/jira/browse/JBAS-7031
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Scott M Stark
            Priority: Critical
             Fix For: JBossAS-5.2.0.Beta1


This should be done in all configurations - default, all, etc.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:06:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 17 Jun 2009 12:06:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6960) once a Topic or
 Queue has been
 stopped via the 'stop' operation, none of its operations or properties
 work, and thus it cannot be restarted using the 'start' operation
In-Reply-To: <11989891.1242832445240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25357601.1245254816635.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer commented on JBAS-6960:
------------------------------------

Ales told Emanuel he should have the MC update checked in by end of day Friday, June 19th.


> once a Topic or Queue has been stopped via the 'stop' operation, none of its operations or properties work, and thus it cannot be restarted using the 'start' operation
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6960
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6960
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Ian Springer
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:09:08 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:09:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-418) JBossPDP evaluate
 needs to be thread safe
In-Reply-To: <12412465.1245254948002.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23549338.1245254948137.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated SECURITY-418:
-----------------------------------

    Fix Version/s: jbossxacml_2.0.3.SP2


> JBossPDP evaluate needs to be thread safe
> -----------------------------------------
>
>                 Key: SECURITY-418
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-418
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossXACML
>    Affects Versions: jbossxacml_2.0.3.SP1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP2
>
>
> PDP evaluation method needs to be thread safe.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:09:07 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:09:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-418) JBossPDP evaluate
 needs to be thread safe
Message-ID: <12412465.1245254948002.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBossPDP evaluate needs to be thread safe
-----------------------------------------

                 Key: SECURITY-418
                 URL: https://jira.jboss.org/jira/browse/SECURITY-418
             Project: JBoss Security and Identity Management
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JBossXACML
    Affects Versions: jbossxacml_2.0.3.SP1
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana


PDP evaluation method needs to be thread safe.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:22:59 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 17 Jun 2009 12:22:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3766163.1245255779562.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-142:
-------------------------------

    Attachment: jbweb-142.patch


Fixed tab/space issue I noticed when applying to patch branch.

> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-142.patch
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:22:58 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 17 Jun 2009 12:22:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17844984.1245255778861.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-142:
-------------------------------

    Attachment:     (was: jbweb-142.patch)


> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-142.patch
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:22:59 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 17 Jun 2009 12:22:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-937) MERGE4: get rid of
 shunning and use only merging (getting rid of shunfests)
In-Reply-To: <27983172.1237998262778.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32324151.1245255779348.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban resolved JGRP-937.
---------------------------

    Resolution: Done


> MERGE4: get rid of shunning and use only merging (getting rid of shunfests)
> ---------------------------------------------------------------------------
>
>                 Key: JGRP-937
>                 URL: https://jira.jboss.org/jira/browse/JGRP-937
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: udp-2.6.xml
>
>
> If we have FD_ALL plus shunning, the following scenario can happen:
> - A network partition with subgroups {A} and {B,C,D,E,F,G}
> - The partition heals
> - A gets heartbeats from all members of the 2nd subgroup
> - A's FD_ALL.shun will shun all members of the 2nd subgroup !
> - And vice versa, this leads to a shunfest and large clusters might never merge back again
> SOLUTION:
> - Get rid of shunning (GMS.shun is false by default anyway, now also set FD/FD_ALL.shun to false)
> - MERGE4 periodically compares discovery results to its view
> (- This might be done a few times)
> - Then MERGE4 initiates a merge between all members who have differing views
> - Make sure digests get merged correctly (min/max)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:36:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-418) JBossPDP evaluate
 needs to be thread safe
In-Reply-To: <12412465.1245254948002.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13927950.1245256616581.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed SECURITY-418.
----------------------------------

    Resolution: Done


Added a lock to the evaluation.  Since the number of locks is low, a reentrant lock is suitable.

> JBossPDP evaluate needs to be thread safe
> -----------------------------------------
>
>                 Key: SECURITY-418
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-418
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossXACML
>    Affects Versions: jbossxacml_2.0.3.SP1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP2
>
>
> PDP evaluation method needs to be thread safe.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:36:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-419) JBossXACML
	2.0.3.SP2 Release
Message-ID: <31884338.1245256616926.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBossXACML 2.0.3.SP2 Release
----------------------------

                 Key: SECURITY-419
                 URL: https://jira.jboss.org/jira/browse/SECURITY-419
             Project: JBoss Security and Identity Management
          Issue Type: Release
      Security Level: Public (Everyone can see)
          Components: jboss-sunxacml, JBossXACML
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:36:57 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:36:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-419) JBossXACML
	2.0.3.SP2 Release
In-Reply-To: <31884338.1245256616926.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13757529.1245256617098.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated SECURITY-419:
-----------------------------------

    Fix Version/s: jbossxacml_2.0.3.SP2


> JBossXACML 2.0.3.SP2 Release
> ----------------------------
>
>                 Key: SECURITY-419
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-419
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: jboss-sunxacml, JBossXACML
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:36:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 17 Jun 2009 12:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-980) VIEW_SYNC: remove it
	from stack
In-Reply-To: <5526265.1242300529250.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <605701.1245256616760.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban resolved JGRP-980.
---------------------------

    Resolution: Done


> VIEW_SYNC: remove it from stack
> -------------------------------
>
>                 Key: JGRP-980
>                 URL: https://jira.jboss.org/jira/browse/JGRP-980
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> VIEW_SYNC is not necessary once we have MERGE4

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:40:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 17 Jun 2009 12:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-87) Started Bootstraps
 are not removed after shutdown
In-Reply-To: <19385748.1243478936539.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26968803.1245256856710.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger updated JBBOOT-87:
--------------------------------------

    Description: During shutdown, we need to remove each bootstrap that's actually been shutdown from the list.  Otherwise they'll be continually marked as "started" even during the next Server restart.  (was: During shutdown, we need to removed each bootstrap that's actually been shutdown from the list.  Otherwise they'll be continually marked as "started" even during the next Server restart.)


> Started Bootstraps are not removed after shutdown
> -------------------------------------------------
>
>                 Key: JBBOOT-87
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-87
>             Project: JBoss Bootstrap
>          Issue Type: Bug
>          Components: impl-base
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>
> During shutdown, we need to remove each bootstrap that's actually been shutdown from the list.  Otherwise they'll be continually marked as "started" even during the next Server restart.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:42:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 17 Jun 2009 12:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-532) Ant tasks not
 passing properties correctly to AS dist build
In-Reply-To: <17089570.1245161096601.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17919277.1245256976722.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Paul Gier closed JBBUILD-532.
-----------------------------

    Resolution: Done


> Ant tasks not passing properties correctly to AS dist build
> -----------------------------------------------------------
>
>                 Key: JBBUILD-532
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-532
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - Maint 2009
>
>
> There is a problem passing properties through the antrun plugin and then to the maven ant tasks.  One of these is not passing system properties correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:42:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 17 Jun 2009 12:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-532) Ant tasks not
 passing properties correctly to AS dist build
In-Reply-To: <17089570.1245161096601.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26786138.1245256976517.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Paul Gier commented on JBBUILD-532:
-----------------------------------

This is fixed in r90340
http://fisheye.jboss.org/changelog/JBossAS/trunk?cs=90340

I added a snapshot version of the maven ant tasks which should be updated after the next release.

> Ant tasks not passing properties correctly to AS dist build
> -----------------------------------------------------------
>
>                 Key: JBBUILD-532
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-532
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - Maint 2009
>
>
> There is a problem passing properties through the antrun plugin and then to the maven ant tasks.  One of these is not passing system properties correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:55:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-419) JBossXACML
	2.0.3.SP2 Release
In-Reply-To: <31884338.1245256616926.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11281269.1245257756475.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed SECURITY-419.
----------------------------------

    Resolution: Done


> JBossXACML 2.0.3.SP2 Release
> ----------------------------
>
>                 Key: SECURITY-419
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-419
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: jboss-sunxacml, JBossXACML
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:58:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-130)
 SOAPSAMLXACMLServlet:: PDP in init method
In-Reply-To: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5132848.1245257936868.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated JBID-130:
-------------------------------

    Summary: SOAPSAMLXACMLServlet:: PDP in init method   (was: SOAPSAMLXACMLServlet:: PDP in init method and threadsafe evaluation)


> SOAPSAMLXACMLServlet:: PDP in init method 
> ------------------------------------------
>
>                 Key: JBID-130
>                 URL: https://jira.jboss.org/jira/browse/JBID-130
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:58:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-130)
 SOAPSAMLXACMLServlet:: PDP in init method and threadsafe evaluation
In-Reply-To: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29592829.1245257936747.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana reopened JBID-130:
--------------------------------



PDP should be created in init method

But since the PDP evaluation is thread safe, we do not need any locking.

> SOAPSAMLXACMLServlet:: PDP in init method and threadsafe evaluation
> -------------------------------------------------------------------
>
>                 Key: JBID-130
>                 URL: https://jira.jboss.org/jira/browse/JBID-130
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 13:26:08 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 13:26:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-130) SOAPSAMLXACMLServlet::
 PDP in init method
In-Reply-To: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15646449.1245259568111.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed JBID-130.
------------------------------

    Resolution: Done


> SOAPSAMLXACMLServlet:: PDP in init method 
> ------------------------------------------
>
>                 Key: JBID-130
>                 URL: https://jira.jboss.org/jira/browse/JBID-130
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 13:43:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 17 Jun 2009 13:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-209) jboss-metadata
 trunk test compilation fails in JDK5
Message-ID: <9131641.1245260636508.JavaMail.jira@cloud.prod.atl2.jboss.com>

jboss-metadata trunk test compilation fails in JDK5
---------------------------------------------------

                 Key: JBMETA-209
                 URL: https://jira.jboss.org/jira/browse/JBMETA-209
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.0.2.Beta2


[INFO] Compilation failure
/home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
symbol  : method stringPropertyNames()
location: class java.util.Properties

/home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
symbol  : method stringPropertyNames()
location: class java.util.Properties

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 13:43:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 17 Jun 2009 13:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7024) results of
 list*Messages methods
 of Queues and Topics have wrong meta type definition
In-Reply-To: <744707.1245166676454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19599636.1245260636693.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-7024.
---------------------------------

    Resolution: Done


I have applied the patch to produce a CompositeValueSupport, but the existing
MapCompositeValue is a CompositeValue and should be seen as consistent with the declared CompositeMetaType.

> results of list*Messages methods of Queues and Topics have wrong meta type definition
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-7024
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7024
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBAPP_5_0 rev90256
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Critical
>         Attachments: JBAS-7024.patch
>
>
> The MessageListMapper used to define the meta types on list*Messages() methods for Queues and Topics advertises that the resulting type will be:
> CollectionMetaType[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> however the meta type of the actual meta values obtained using collectionValue.getElements() is advertised as:
> MapCompositeValue[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> This discrepancy is affecting the admin console, Jopr and JON because the meta values values have different type than the advertised meta type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 13:45:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 17 Jun 2009 13:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7024) results of
 list*Messages methods
 of Queues and Topics have wrong meta type definition
In-Reply-To: <744707.1245166676454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27811850.1245260756564.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark updated JBAS-7024:
--------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> results of list*Messages methods of Queues and Topics have wrong meta type definition
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-7024
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7024
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBAPP_5_0 rev90256
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: JBAS-7024.patch
>
>
> The MessageListMapper used to define the meta types on list*Messages() methods for Queues and Topics advertises that the resulting type will be:
> CollectionMetaType[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> however the meta type of the actual meta values obtained using collectionValue.getElements() is advertised as:
> MapCompositeValue[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> This discrepancy is affecting the admin console, Jopr and JON because the meta values values have different type than the advertised meta type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 13:45:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 17 Jun 2009 13:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-209) jboss-metadata
 trunk test compilation fails in JDK5
In-Reply-To: <9131641.1245260636508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16389016.1245260756719.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger resolved JBMETA-209.
----------------------------------------

    Resolution: Done


> jboss-metadata trunk test compilation fails in JDK5
> ---------------------------------------------------
>
>                 Key: JBMETA-209
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-209
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.0.2.Beta2
>
>
> [INFO] Compilation failure
> /home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
> symbol  : method stringPropertyNames()
> location: class java.util.Properties
> /home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
> symbol  : method stringPropertyNames()
> location: class java.util.Properties

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:01:56 2009
From: jira-events at lists.jboss.org (Scott Clasen (JIRA))
Date: Wed, 17 Jun 2009 15:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
Message-ID: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>

Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
--------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1658
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta2
         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.


            Reporter: Scott Clasen
            Assignee: Tim Fox


Clocks on the 2 boxes are in sync so notice the times in the log entries below.

PRIMARY

13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
...MESSAGE REPEATS TILL SERVER KILLED...

=======================================================================================================================================
SECONDARY


14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
...MESSAGE REPEATS TILL SERVER KILLED...


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:03:56 2009
From: jira-events at lists.jboss.org (Scott Clasen (JIRA))
Date: Wed, 17 Jun 2009 15:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10203119.1245265436858.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott Clasen updated JBMESSAGING-1658:
--------------------------------------

    Attachment: threadDumps.txt


Thread dumps of both servers

> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:19:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Wed, 17 Jun 2009 15:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <19505031.1245266396893.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene moved EMBJOPR-194 to JBAS-7032:
-----------------------------------------------

              Project: JBoss Application Server  (was: Embedded Jopr)
                  Key: JBAS-7032  (was: EMBJOPR-194)
          Component/s: Deployers
                           (was: Core Infrastructure)
    Affects Version/s:     (was: 1.2)
             Security: Public


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Ian Springer
>            Priority: Minor
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:22:02 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Wed, 17 Jun 2009 15:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <27866982.1245266522046.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene reassigned JBAS-7032:
-------------------------------------

    Assignee: Scott Marlow  (was: Ian Springer)


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Scott Marlow
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:22:02 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Wed, 17 Jun 2009 15:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <24349631.1245266522427.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene commented on JBAS-7032:
---------------------------------------

If this problem happens during hot deploy then its likely a general AS issue. I have moved it to the AS project

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Scott Marlow
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:22:02 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Wed, 17 Jun 2009 15:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <9669355.1245266522224.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene updated JBAS-7032:
----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
         Priority: Major  (was: Minor)


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Scott Marlow
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:23:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Wed, 17 Jun 2009 15:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <10262616.1245266636682.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene commented on JBAS-7032:
---------------------------------------

It looks like classloading isn't there...

Caused by: java.lang.IllegalArgumentException: No module in deployment unit's hierarchy: vfszip:/usr
/local/jboss/jboss-5.1.0.GA/server/default/deploy/ImageServer.ear/imageserver-ejb.jar/
	at org.jboss.deployers.vfs.plugins.annotations.AnnotationEnvironmentDeployer.deploy(AnnotationEnvir
onmentDeployer.java:229)
	at org.jboss.deployers.vfs.plugins.annotations.AnnotationEnvironmentDeployer.deploy(AnnotationEnvir
onmentDeployer.java:48)
	at org.jboss.deployers.vfs.spi.deployer.AbstractOptionalVFSRealDeployer.deploy(AbstractOptionalVFSR
ealDeployer.java:57)
	at org.jboss.deployers.spi.deployer.helpers.AbstractOptionalRealDeployer.internalDeploy(AbstractOpt
ionalRealDeployer.java:74)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:5
0)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	... 38 more


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Scott Marlow
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:29:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Wed, 17 Jun 2009 15:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-210) Validation errors
 in some jboss-___.5_x.xsd files
Message-ID: <21174263.1245266996482.JavaMail.jira@cloud.prod.atl2.jboss.com>

Validation errors in some jboss-___.5_x.xsd files
-------------------------------------------------

                 Key: JBMETA-210
                 URL: https://jira.jboss.org/jira/browse/JBMETA-210
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: Eclipse 3.4.2/WebToolsPlatform 3.0.4
            Reporter: Wolfgang Knauf
            Assignee: Alexey Loubyansky


Some more schema definitions for 5.0/5.1 contain validation errors (which will raise validation errors if building instances in Eclipse). The problem is that includes/imports don't point to the web locations.
The same issue arose for jboss-5.1.xsd: https://jira.jboss.org/jira/browse/JBMETA-200

jboss-web_5_1.xsd:

   <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>
   <xsd:include schemaLocation="jboss-common_5_1.xsd"/>

Change to:
   <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>
   <xsd:include schemaLocation="http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd"/>

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

jboss-ds_5_0.xsd:
   <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>
   <xsd:include schemaLocation="jboss-common_5_1.xsd"/>

Change to:

   <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>
   <xsd:include schemaLocation="http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd"/>
   
===================    

jboss-client_5_1.xsd
   <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>
   <xsd:include schemaLocation="jboss-common_5_1.xsd"/>

Change to:

   <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>
   <xsd:include schemaLocation="http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd"/>
   


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:38:08 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Wed, 17 Jun 2009 15:38:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <29107786.1245267488399.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

John Ament commented on JBAS-7032:
----------------------------------

Classloading on what exactly?  BTW, since it happens in both hot and cold deployments (e.g. copy file to deploy while app server off) it seemed like more of a JOPR issue.  

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Scott Marlow
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:41:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 15:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7033) Upgrade to
	JBossXACML 2.0.3.SP2
Message-ID: <13425312.1245267716521.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade to JBossXACML 2.0.3.SP2 
--------------------------------

                 Key: JBAS-7033
                 URL: https://jira.jboss.org/jira/browse/JBAS-7033
             Project: JBoss Application Server
          Issue Type: Component Upgrade
      Security Level: Public (Everyone can see)
          Components: Security
            Reporter: Anil Saldhana
            Assignee: Stefan Guilhen
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


Upgrade to JBossXACML 2.0.3.SP2

Branch_5_x, trunk and the branch corresponding to EAP5 (find out what branch is that).

Just update the component/pom.xml

Run the   ant   tests-security-basic-unit test target and see if there are regressions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:43:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Wed, 17 Jun 2009 15:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7034) Outdated/missing
 schema files on website
Message-ID: <15960137.1245267836412.JavaMail.jira@cloud.prod.atl2.jboss.com>

Outdated/missing schema files on website
----------------------------------------

                 Key: JBAS-7034
                 URL: https://jira.jboss.org/jira/browse/JBAS-7034
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Wolfgang Knauf


Some xsd files are missing or are outdated at http://www.jboss.org/j2ee/schema/

Please update from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/):

jboss-ds_5_0.xsd (missing)
jboss-web_5_1.xsd (missing)
jboss_common_5_1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.0.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-185 )
(some still do not validate because of invalid schema locations, so they must be updated again if https://jira.jboss.org/jira/browse/JBMETA-210 is fixed)

bean-deployer_1_0.xsd (missing)
bean-deployer_2_0.xsd (missing)
jboss-beans-common_2_0.xsd (missing)
policy_1_0.xsd (missing)
Note: they do not validate, too (invalid schema locations, and a (maybe false) validation error), but they should be available on the website anyway.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:45:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 15:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7033) Upgrade to
	JBossXACML 2.0.3.SP2
In-Reply-To: <13425312.1245267716521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29437119.1245267956577.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana commented on JBAS-7033:
-------------------------------------

JBPAPP_5_0/

> Upgrade to JBossXACML 2.0.3.SP2 
> --------------------------------
>
>                 Key: JBAS-7033
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7033
>             Project: JBoss Application Server
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Upgrade to JBossXACML 2.0.3.SP2
> Branch_5_x, trunk and the branch corresponding to EAP5 (find out what branch is that).
> Just update the component/pom.xml
> Run the   ant   tests-security-basic-unit test target and see if there are regressions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:55:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 17 Jun 2009 15:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6777) 'interleaving' prop
 on connection
 factories and datasources is always null, even when underlying ds.xml file
 contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10903454.1245268556692.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark updated JBAS-6777:
--------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238330


See the forum thread for why this property cannot be true on a non-XA factory

> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:57:56 2009
From: jira-events at lists.jboss.org (Jonathon Leibundguth (JIRA))
Date: Wed, 17 Jun 2009 15:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2114) Drools hangs
 with deadlock
 after it has initialized a rule (in multithreaded environment)
In-Reply-To: <30331207.1244203927899.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24259987.1245268676653.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jonathon Leibundguth commented on JBRULES-2114:
-----------------------------------------------

Believe I am seeing this same deadlock issue in the 5.0 release.

> Drools hangs with deadlock after it has initialized a rule (in multithreaded environment)
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2114
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2114
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 4.0.6
>            Reporter: Andrey Nechaev
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: patch-AbstractRuleBase
>
>
> Here is a scenario when drools core hangs with a deadlock:
> Suppose we heve a rule throwing an exception in the RHS. 
> So, if:
> 1. Thread A updates the Rule Base with the rule 
> 2. The rule fires (current thread is Thread A)
> 3. Rule's RHS throws an exception (still having Thread A as current)
> 4. Thread B tries to update the Rule Base or the Working Memory (for example, the Thread B inserts a fact)
> in such a case the Thread B falls into infinite wait() loop.
> Here is the test case showing such a behavior:
> package com.test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> public class DroolsTest2 {
> 	private final static String rule = "" + 
> 	"package test\n" +
> 	"import com.test.DroolsTest2;\n" +
> 	"rule test\n" +
> 		"\twhen\n" +
> 		"\tthen\n" +
> 			"\t\tDroolsTest2.fail();" +
> 	"end";
> 	
> 	private static Object sem = new Object();
> 	private static boolean seed = false;
> 	
> 	public static void main(String[] args) throws Exception {
> 		final RuleBase rb = RuleBaseFactory.newRuleBase();
> 		final WorkingMemory wm = rb.newStatefulSession();
> 		new Thread(new Runnable() {
> 			@Override
> 			public void run() {
> 				seed = false;
> 				PackageBuilder bld = new PackageBuilder();
> 				try {
> 					bld.addPackageFromDrl(new StringReader(rule));				
> 					rb.addPackage(bld.getPackage());
> 				} catch(Exception e) {					
> 				} finally {
> 					synchronized (sem) {
> 						seed = true;
> 						sem.notify();
> 					}
> 				}
> 			}
> 		}).start();
> 		Thread ins = new Thread(new Runnable() {
> 			@Override
> 			public void run() {
> 				while(!seed) {
> 					synchronized (sem) {
> 						try {
> 							sem.wait();
> 						} catch (InterruptedException e) {}
> 					}
> 				}
> 				wm.insert(new Object());
> 			}
> 		});
> 		ins.start();
> 		ins.join();
> 	}
> 	
> 	public static void fail() {
> 		throw new IllegalStateException("fail!");
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 16:00:07 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 16:00:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-420) JBoss Security
 2.0.3.SP2 Release
Message-ID: <14028107.1245268807366.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBoss Security 2.0.3.SP2 Release
--------------------------------

                 Key: SECURITY-420
                 URL: https://jira.jboss.org/jira/browse/SECURITY-420
             Project: JBoss Security and Identity Management
          Issue Type: Release
      Security Level: Public (Everyone can see)
          Components: JBossSX, Security SPI
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 16:01:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 16:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-420) JBoss Security
 2.0.3.SP2 Release
In-Reply-To: <14028107.1245268807366.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23764798.1245268916438.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated SECURITY-420:
-----------------------------------

    Fix Version/s: JBossSecurity_2.0.3.SP2


> JBoss Security 2.0.3.SP2 Release
> --------------------------------
>
>                 Key: SECURITY-420
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-420
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 16:18:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 16:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-420) JBoss Security
 2.0.3.SP2 Release
In-Reply-To: <14028107.1245268807366.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2346242.1245269936420.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana closed SECURITY-420.
----------------------------------

    Resolution: Done


> JBoss Security 2.0.3.SP2 Release
> --------------------------------
>
>                 Key: SECURITY-420
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-420
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 16:29:56 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 17 Jun 2009 16:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7035) Help avoid unneeded
 scanning of classes for annotations by adding jboss-scanning.xml
Message-ID: <32851153.1245270596605.JavaMail.jira@cloud.prod.atl2.jboss.com>

Help avoid unneeded scanning of classes for annotations by adding jboss-scanning.xml
------------------------------------------------------------------------------------

                 Key: JBAS-7035
                 URL: https://jira.jboss.org/jira/browse/JBAS-7035
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Web Services
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Scott Marlow
            Assignee: Alessio Soldano
             Fix For: JBossAS-6.0.0.Alpha1
         Attachments: jboss-scanning.xml

Please add the attached jboss-scanning.xml file to folders:
  jbossws.sar/jbossws-management.war/META-INF
  jbossws.sar/jbossws-management.war/WEB-INF


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 16:29:56 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 17 Jun 2009 16:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7035) Help avoid unneeded
 scanning of classes for annotations by adding jboss-scanning.xml
In-Reply-To: <32851153.1245270596605.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24379987.1245270596915.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott Marlow updated JBAS-7035:
-------------------------------

    Attachment: jboss-scanning.xml


> Help avoid unneeded scanning of classes for annotations by adding jboss-scanning.xml
> ------------------------------------------------------------------------------------
>
>                 Key: JBAS-7035
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7035
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott Marlow
>            Assignee: Alessio Soldano
>             Fix For: JBossAS-6.0.0.Alpha1
>
>         Attachments: jboss-scanning.xml
>
>
> Please add the attached jboss-scanning.xml file to folders:
>   jbossws.sar/jbossws-management.war/META-INF
>   jbossws.sar/jbossws-management.war/WEB-INF

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 16:31:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 17 Jun 2009 16:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15366401.1245270716524.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox commented on JBMESSAGING-1658:
--------------------------------------

Scott, just to let you know:

I have been running two servers, on different nodes with your config, fine for 4 hours now with no errors, let's see how it is in the morning.

> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 16:59:56 2009
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Wed, 17 Jun 2009 16:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7036) Wrong server.xml may
	be loaded
Message-ID: <28044856.1245272396732.JavaMail.jira@cloud.prod.atl2.jboss.com>

Wrong server.xml may be loaded
------------------------------

                 Key: JBAS-7036
                 URL: https://jira.jboss.org/jira/browse/JBAS-7036
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Tomcat) service
    Affects Versions: JBossAS-4.2.3.GA
            Reporter: Dennis Reed
            Assignee: Remy Maucherat


JBoss AS does not specify the path to server.xml, allowing JBossWeb to choose the wrong file.

The file is only specified as "server.xml".  JBossWeb looks for ${catalina.base}/server.xml, where catalina.base is ${jboss.server.home.dir}.
If it fails to find it there (currently the normal case), it then searches the classpath for server.xml.

If there is another server.xml in ${jboss.server.home.dir}/server.xml or anywhere in the classpath, it may get used instead.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 17:12:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 17 Jun 2009 17:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2425) It should be
 possible to concatenate context path to relative URL in WSRP context
Message-ID: <27700505.1245273176369.JavaMail.jira@cloud.prod.atl2.jboss.com>

It should be possible to concatenate context path to relative URL in WSRP context
---------------------------------------------------------------------------------

                 Key: JBPORTAL-2425
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2425
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.7.2 Final
            Reporter: Chris Laprun
            Assignee: Chris Laprun
            Priority: Minor
             Fix For: 2.7.3 Final


In particular: renderResponse.encodeURL(renderRequest.getContextPath()) + "/something" should result in a valid URL in a WSRP context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 17:14:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 17 Jun 2009 17:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2426) URLTools should
 detect applet archive URLs
Message-ID: <33386362.1245273296381.JavaMail.jira@cloud.prod.atl2.jboss.com>

URLTools should detect applet archive URLs
------------------------------------------

                 Key: JBPORTAL-2426
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2426
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.7.2 Final
            Reporter: Chris Laprun
            Assignee: Chris Laprun
             Fix For: 2.7.3 Final




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 17:24:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 17 Jun 2009 17:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-2426) URLTools should
 detect applet archive URLs
In-Reply-To: <33386362.1245273296381.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15211714.1245273896431.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Chris Laprun resolved JBPORTAL-2426.
------------------------------------

    Resolution: Done


> URLTools should detect applet archive URLs
> ------------------------------------------
>
>                 Key: JBPORTAL-2426
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2426
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.7.2 Final
>            Reporter: Chris Laprun
>            Assignee: Chris Laprun
>             Fix For: 2.7.3 Final
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 17:29:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 17 Jun 2009 17:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-522) Set properties
 related to the build environment in jar.
In-Reply-To: <20490295.1238020522431.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20416285.1245274196844.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Paul Gier closed JBBUILD-522.
-----------------------------

    Resolution: Done


Fixed in r90360.

> Set properties related to the build environment in jar.
> -------------------------------------------------------
>
>                 Key: JBBUILD-522
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-522
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - Maint 2009
>
>
> It is useful to have details about the build environment contained in the maven repository.  Either in a text file or inside the deployed jar.  The most practical way to do this seems to be setting properties in the manifest that contains information about java version, OS, maven version, and svn revision.
> The java version and OS can be gathered from standard maven properties.  The svn revision can be set in a property using the buildnumber-maven-plugin.  There currently does not appear to be an easy way to record the version of maven that was used during the build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 17:29:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 17 Jun 2009 17:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-2425) It should be
 possible to concatenate context path to relative URL in WSRP context
In-Reply-To: <27700505.1245273176369.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4770608.1245274196700.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Chris Laprun resolved JBPORTAL-2425.
------------------------------------

    Resolution: Done


> It should be possible to concatenate context path to relative URL in WSRP context
> ---------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2425
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2425
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.7.2 Final
>            Reporter: Chris Laprun
>            Assignee: Chris Laprun
>            Priority: Minor
>             Fix For: 2.7.3 Final
>
>
> In particular: renderResponse.encodeURL(renderRequest.getContextPath()) + "/something" should result in a valid URL in a WSRP context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 19:12:56 2009
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 17 Jun 2009 19:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2127)
 KnowledgeBase.getKnowledgePackage(String str) should return null if package
 does not exist
Message-ID: <27626257.1245280376657.JavaMail.jira@cloud.prod.atl2.jboss.com>

KnowledgeBase.getKnowledgePackage(String str) should return null if package does not exist
------------------------------------------------------------------------------------------

                 Key: JBRULES-2127
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2127
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-api
            Reporter: Mark Proctor
            Assignee: Mark Proctor
             Fix For: 5.1.0.M1


currently it's returning an empty KnowledgePackage, if it does not exist, it should return null.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 19:22:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 17 Jun 2009 19:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27177999.1245280976548.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger commented on JBAS-7008:
-------------------------------------------

Are you sure EntityTestBean is an entity, not some SLSB used to test entities?  Because these metrics make no sense for entities; they're not invoked, we don't track create counts, etc.

> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 19:42:56 2009
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 17 Jun 2009 19:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2127)
 KnowledgeBase.getKnowledgePackage(String str) should return null if package
 does not exist
In-Reply-To: <27626257.1245280376657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12572348.1245282176669.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mark Proctor closed JBRULES-2127.
---------------------------------

    Resolution: Done


> KnowledgeBase.getKnowledgePackage(String str) should return null if package does not exist
> ------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2127
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2127
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-api
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 5.1.0.M1
>
>
> currently it's returning an empty KnowledgePackage, if it does not exist, it should return null.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 20:31:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Wed, 17 Jun 2009 20:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10519516.1245285116535.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene commented on JBAS-7008:
---------------------------------------

There are no JMX entries for EJB3 entities, since they are *not* managed by the container. I think hibernate stats is really what you are after, that is the only part of the system that knows what an entity is.

> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 20:55:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 17 Jun 2009 20:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4183452.1245286556638.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer commented on JBAS-7008:
------------------------------------

Yeah, my bad. EntityTestBean is indeed an SLSB. Jason, is it possible for you to use some Hibernate API to obtain the list of deployed entities and their associated deployments?


> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 22:21:56 2009
From: jira-events at lists.jboss.org (Ronn C (JIRA))
Date: Wed, 17 Jun 2009 22:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Admin Join problem
 -GMS flush by coordinator failed
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29605691.1245291716718.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ronn C commented on JGRP-985:
-----------------------------

I'm now using 2.6.10.merge. Will be deploying to prod soon but rather nervous about it.

> having three nodes fail at the same time.

Yes I think your guess is right, something in the coordinator must be corrupted and once failure happens on one node, it will happen to other node that wants to join.

I had tried to debug the problem and I got as far as the coordinator had received JOIN request and as part of processing the JOIN request it was trying to do a flush but flush return false as a result it doesn't generate JOIN response and add the member in. 

The code that implement flush rather hard to follow and I was hoping that there would be a document that would explain to me how flush work in algorithmic form so that it would give me a bit of context to what/where I should be looking out for. Is there such a thing? If not could you explain it to me and I'll try to debug it again. 




> Admin  Join problem -GMS flush by coordinator failed
> ----------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 23:17:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Wed, 17 Jun 2009 23:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-736) Create workaround for
 IBM JVM's Clas.getDeclaringClass bug
In-Reply-To: <33122186.1245199796446.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24519667.1245295076428.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Flavia Rainone closed JBAOP-736.
--------------------------------

    Resolution: Done


> Create workaround for IBM JVM's Clas.getDeclaringClass bug
> ----------------------------------------------------------
>
>                 Key: JBAOP-736
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-736
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>             Fix For: 2.1.2.GA
>
>
> The IBM's JVM returns null when the generated advisor's constructor invokes this.getClass().getDeclaringClass(), thus causing JBoss AOP from version 2.0 on to not work with IBM's JVM.
> The call to getDeclaringClass() needs to be replaced.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 00:32:56 2009
From: jira-events at lists.jboss.org (Calvin Lin (JIRA))
Date: Thu, 18 Jun 2009 00:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7037) JBossAS 5.x fails to
 use EJB's
 security domain in jboss.xml when the call is from web container
Message-ID: <2821553.1245299576703.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBossAS 5.x fails to use EJB's security domain in jboss.xml when the call is from web container
-----------------------------------------------------------------------------------------------

                 Key: JBAS-7037
                 URL: https://jira.jboss.org/jira/browse/JBAS-7037
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.0.1.GA
         Environment: Problem found on Windows platform
            Reporter: Calvin Lin
            Assignee: Anil Saldhana
            Priority: Critical


A degredation from JBoss 4.0.x and 4.2.x to JBoss 5.0.1.GA and JBoss 5.1.0.GA.

We noticed that the JAAS login in EJB container always picks up the Web app's security domain when the client login is originated from a web application client.  The security domain specified in EJB container's jboss.xml is always ignored in this situation.

The detailed problem description is posted on JBoss forum:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156863

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 00:49:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 00:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24815718.1245300597131.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic closed JBMESSAGING-1646.
----------------------------------------

    Resolution: Done


Scott Clasen has opened a new issue (JBMESSAGING-1656). 

> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>         Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>             Fix For: 2.0.0.beta2
>
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 01:06:56 2009
From: jira-events at lists.jboss.org (Calvin Lin (JIRA))
Date: Thu, 18 Jun 2009 01:06:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7037) JBossAS 5.x fails to
 use EJB's
 security domain in jboss.xml when the call is from web container
In-Reply-To: <2821553.1245299576703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15952010.1245301616545.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Calvin Lin updated JBAS-7037:
-----------------------------

    Attachment: JBAS-jira-authenBug.zip


The zip file contains the web and ejb project that demonstrate the problem.
Please read readme.txt first.
The project uses JBossAS 5.1.0.GA.

> JBossAS 5.x fails to use EJB's security domain in jboss.xml when the call is from web container
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7037
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: Problem found on Windows platform
>            Reporter: Calvin Lin
>            Assignee: Anil Saldhana
>            Priority: Critical
>         Attachments: JBAS-jira-authenBug.zip
>
>
> A degredation from JBoss 4.0.x and 4.2.x to JBoss 5.0.1.GA and JBoss 5.1.0.GA.
> We noticed that the JAAS login in EJB container always picks up the Web app's security domain when the client login is originated from a web application client.  The security domain specified in EJB container's jboss.xml is always ignored in this situation.
> The detailed problem description is posted on JBoss forum:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156863

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 01:32:23 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 18 Jun 2009 01:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19784927.1245303143196.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox commented on JBMESSAGING-1658:
--------------------------------------

As of this morning, the servers have been sitting idle for over 12 hours with no errors

[tfox at messaging-01 logs]$ date
Thu Jun 18 01:30:01 EDT 2009


> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 01:36:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 18 Jun 2009 01:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2418205.1245303416601.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox commented on JBMESSAGING-1658:
--------------------------------------

Scott- if you could give me _exact_ instructions for replicating this it would help a lot, i.e. exact list of command lines etc, since I may be doing something different from you.

Basically I just started two nodes, live and backup on the same network using your config. The only difference I can see is I am not using virtualization.

Are you absolutely sure no one else is using the same network as you (you might get UDP interference from other servers).

> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 01:38:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 18 Jun 2009 01:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-207)
 NullPointerException during
 deployment of EJB3 methods with zero parameters
In-Reply-To: <31747213.1244728808387.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17985649.1245303536792.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472636#action_12472636 ] 

Andrew Lee Rubinger commented on JBMETA-207:
--------------------------------------------

Note: The test for JBMETA-152 uses SecureService.someMethod, which accepts no method parameters.  Why does this not result in NPE?

Zachary, could you attach the relevant sources for the deployable leading to this?  The fix is easy enough, but should be verified with a failing test that gets corrected.

> NullPointerException during deployment of EJB3 methods with zero parameters
> ---------------------------------------------------------------------------
>
>                 Key: JBMETA-207
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-207
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.0.GA
>         Environment: JBoss-5.1.0-GA, JDK 1.6.0_07-b06-153 (Apple/Sun JVM, 64-bit on OS/X), EJB3 w/ descriptor overrides
>            Reporter: Zachary Bedell
>            Assignee: Andrew Lee Rubinger
>         Attachments: fixJBMETA207.patch
>
>
> Deploying an EJB3 based EAR results in an NPE with the below stack trace.  The problem appears to manifest with EJB3's containing methods that take zero arguments.  There are also XML descriptor based attributes for several of the metadata elements.  To the best of my knowledge the descriptors only augment, not override anything specified in annotations.
> Patch for this should be trivial (an additional null check on line 83 of RolesAllowedProcessor.java should do it).  I'm in the process of attempting to get JBMETA built from source and integrated into my stack.  Will attach patch & tests unless someone beats me to it.
> The stack:
> 09:44:51,219 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=vfszip:/jboss/jboss-eap-5.0/server/ucmsfc/deploy/ucms.ear/ state=ClassLoader mode=Manual requiredState=PostClassLoader
> org.jboss.deployers.spi.DeploymentException: Cannot process metadata
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:181)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:93)
> 	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.install(DeployersImpl.java:1098)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:698)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:59)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:355)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:310)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:241)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 	at org.jboss.Main.boot(Main.java:216)
> 	at org.jboss.Main$1.run(Main.java:546)
> 	at java.lang.Thread.run(Thread.java:637)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:83)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:48)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:215)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:172)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:151)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:94)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:52)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.process(AbstractCreator.java:154)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.processMetaData(AbstractCreator.java:87)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator.create(JBoss50Creator.java:109)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processJBossMetaData(OptAnnotationMetaDataDeployer.java:134)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processMetaData(OptAnnotationMetaDataDeployer.java:84)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:177)
> 	... 31 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 02:10:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 18 Jun 2009 02:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-211) eclipse env setup
Message-ID: <7526884.1245305456586.JavaMail.jira@cloud.prod.atl2.jboss.com>

eclipse env setup
-----------------

                 Key: JBMETA-211
                 URL: https://jira.jboss.org/jira/browse/JBMETA-211
             Project: JBoss Metadata
          Issue Type: Task
      Security Level: Public (Everyone can see)
         Environment: eclipse IDE
            Reporter: Jeff Zhang
            Assignee: Alexey Loubyansky
            Priority: Minor


in the new common diectory, the eclipse project name is "common" defined in .project file, that is easy to conflict with other name, I suggest it should be like "jboss-metadata-common"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 02:18:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 18 Jun 2009 02:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3211797.1245305936821.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

The namespace is what distinguishes EJB2 descriptor from EJB3. DTDs don't have a namespace. EJB2 and EJB1 schemas are based on DTDs, so when a descriptor w/o a namespace is found it assumed to be EJB2.x one.
This is also how the metadata classes are bound with JAXB/JBossXB annotations. EJB3 metadata classes (as any Java class in principle) are bound to a specific namespace, which is http://java.sun.com/xml/ns/javaee in case of EJB3.

Although, we could make it work w/o a namespace (by copying EjbJar30MetaData class, binding it to an empty namespace and adjusting metadata version resolution logic (which will be now done outside of XB's SchemaResolver impl, but by a deployer probably)), I am so far not in favor of supporting this.

If you are writing an XML based on an XSD it is a given to include the namespace from the XSD. So, I would fix the EJB3 docs instead.

PS: the forum link is not really about this issue.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 02:20:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 18 Jun 2009 02:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-211) eclipse env setup
In-Reply-To: <7526884.1245305456586.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3010807.1245306056737.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472641#action_12472641 ] 

Jeff Zhang commented on JBMETA-211:
-----------------------------------

add eclipse env files for rar, r90373

> eclipse env setup
> -----------------
>
>                 Key: JBMETA-211
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-211
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>         Environment: eclipse IDE
>            Reporter: Jeff Zhang
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> in the new common diectory, the eclipse project name is "common" defined in .project file, that is easy to conflict with other name, I suggest it should be like "jboss-metadata-common"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 03:01:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 18 Jun 2009 03:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-212) rar annotation
	processing
Message-ID: <2713687.1245308516586.JavaMail.jira@cloud.prod.atl2.jboss.com>

rar annotation processing
-------------------------

                 Key: JBMETA-212
                 URL: https://jira.jboss.org/jira/browse/JBMETA-212
             Project: JBoss Metadata
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 1.0.2.Beta1
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang


handle jca 1.6 annotation

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 03:17:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 18 Jun 2009 03:17:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7591476.1245309477428.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger resolved JBAS-7008.
---------------------------------------

    Resolution: Won't Fix


> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 03:26:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 18 Jun 2009 03:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-211) eclipse env setup
In-Reply-To: <7526884.1245305456586.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22619057.1245310016909.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472646#action_12472646 ] 

Alexey Loubyansky commented on JBMETA-211:
------------------------------------------

eclipse project info was generated by mvn eclipse:eclipse. Originally I used common, client, ejb, etc as artifactId. Then I changed it to metadata-common, metadata-client, metadata-ejb, etc. So, regeneration should fix it.

> eclipse env setup
> -----------------
>
>                 Key: JBMETA-211
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-211
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>         Environment: eclipse IDE
>            Reporter: Jeff Zhang
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> in the new common diectory, the eclipse project name is "common" defined in .project file, that is easy to conflict with other name, I suggest it should be like "jboss-metadata-common"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 03:34:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 18 Jun 2009 03:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-211) eclipse env setup
In-Reply-To: <7526884.1245305456586.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8918783.1245310496564.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472647#action_12472647 ] 

Alexey Loubyansky commented on JBMETA-211:
------------------------------------------

Fixed for common (metadata-common) and ejb (metadata-ejb).

> eclipse env setup
> -----------------
>
>                 Key: JBMETA-211
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-211
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>         Environment: eclipse IDE
>            Reporter: Jeff Zhang
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> in the new common diectory, the eclipse project name is "common" defined in .project file, that is easy to conflict with other name, I suggest it should be like "jboss-metadata-common"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 03:38:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 18 Jun 2009 03:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-211) eclipse env setup
In-Reply-To: <7526884.1245305456586.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5904890.1245310736595.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472649#action_12472649 ] 

Jeff Zhang commented on JBMETA-211:
-----------------------------------

thanks Alex.
I use "jboss-metadata-rar" for rar part, I will change it to match your naming after next code submit.

> eclipse env setup
> -----------------
>
>                 Key: JBMETA-211
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-211
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>         Environment: eclipse IDE
>            Reporter: Jeff Zhang
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> in the new common diectory, the eclipse project name is "common" defined in .project file, that is easy to conflict with other name, I suggest it should be like "jboss-metadata-common"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 03:40:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 18 Jun 2009 03:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-211) eclipse env setup
In-Reply-To: <7526884.1245305456586.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25827950.1245310856542.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472650#action_12472650 ] 

Alexey Loubyansky commented on JBMETA-211:
------------------------------------------

I guess eclipse project name is not a big deal. You can use whatever you want. What we all have to agree on is a common artifactId format.

> eclipse env setup
> -----------------
>
>                 Key: JBMETA-211
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-211
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>         Environment: eclipse IDE
>            Reporter: Jeff Zhang
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> in the new common diectory, the eclipse project name is "common" defined in .project file, that is easy to conflict with other name, I suggest it should be like "jboss-metadata-common"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 04:22:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 18 Jun 2009 04:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMETA-211) eclipse env setup
In-Reply-To: <7526884.1245305456586.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30238293.1245313376616.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Zhang closed JBMETA-211.
-----------------------------

    Resolution: Done


> eclipse env setup
> -----------------
>
>                 Key: JBMETA-211
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-211
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>         Environment: eclipse IDE
>            Reporter: Jeff Zhang
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> in the new common diectory, the eclipse project name is "common" defined in .project file, that is easy to conflict with other name, I suggest it should be like "jboss-metadata-common"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:01:07 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 18 Jun 2009 05:01:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1659) Create source
	distribution
Message-ID: <1154159.1245315667976.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create source distribution
--------------------------

                 Key: JBMESSAGING-1659
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1659
             Project: JBoss Messaging
          Issue Type: Task
          Components: Build System
    Affects Versions: 2.0.0 Beta1
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 2.0.0


JBoss Messaging build systems creates only binary distributions.
We must also create source distributions which contains the source.

An alternative is to always include the source in the distributions (the src dir is 4,4M and 1M when zipped)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:01:08 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 18 Jun 2009 05:01:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1659) Create source
	distribution
In-Reply-To: <1154159.1245315667976.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28342948.1245315668222.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil updated JBMESSAGING-1659:
-------------------------------------

    Affects Version/s: 2.0.0.beta2
                           (was: 2.0.0 Beta1)


> Create source distribution
> --------------------------
>
>                 Key: JBMESSAGING-1659
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1659
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>    Affects Versions: 2.0.0.beta2
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> JBoss Messaging build systems creates only binary distributions.
> We must also create source distributions which contains the source.
> An alternative is to always include the source in the distributions (the src dir is 4,4M and 1M when zipped)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:10:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMDR-58) Update to
 jboss-common-core 2.2.14.GA
Message-ID: <5995551.1245316256601.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update to jboss-common-core 2.2.14.GA
-------------------------------------

                 Key: JBMDR-58
                 URL: https://jira.jboss.org/jira/browse/JBMDR-58
             Project: JBoss MetaData Repository
          Issue Type: Thirdparty Change
          Components: Release
    Affects Versions: JBossMDR-2.0.1.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBossMDR-2.0.2.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:12:58 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:12:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMDR-59) Release JBoss MDR
	2.0.2.GA
Message-ID: <31196864.1245316378255.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release JBoss MDR 2.0.2.GA
--------------------------

                 Key: JBMDR-59
                 URL: https://jira.jboss.org/jira/browse/JBMDR-59
             Project: JBoss MetaData Repository
          Issue Type: Release
          Components: Release
    Affects Versions: JBossMDR-2.0.1.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBossMDR-2.0.2.GA


Release notes:
 - https://jira.jboss.org/jira/secure/ReleaseNote.jspa?version=12312897&styleName=Text&projectId=12310561&Create=Create

MVN repo:
 - http://anonsvn.jboss.org/repos/repository.jboss.org/maven2/org/jboss/jboss-mdr/2.0.2.GA/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:12:59 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:12:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMDR-5) Test annotation
 overrides at the Thread level in the metadata repository
Message-ID: <13463366.1245316379499.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin updated JBMDR-5:
----------------------------

    Fix Version/s: JBossMDR-2.2.0.Alpha1
                       (was: JBossMDR-2.0.2.GA)


> Test annotation overrides at the Thread level in the metadata repository
> ------------------------------------------------------------------------
>
>                 Key: JBMDR-5
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-5
>             Project: JBoss MetaData Repository
>          Issue Type: Sub-task
>          Components: Tests
>            Reporter: Adrian Brock
>             Fix For: JBossMDR-2.2.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:12:59 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:12:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMDR-4) Test metadata for all
	joinpoints
Message-ID: <15882055.1245316379871.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin updated JBMDR-4:
----------------------------

    Fix Version/s: JBossMDR-2.2.0.Alpha1
                       (was: JBossMDR-2.0.2.GA)


> Test metadata for all joinpoints
> --------------------------------
>
>                 Key: JBMDR-4
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-4
>             Project: JBoss MetaData Repository
>          Issue Type: Sub-task
>          Components: Tests
>            Reporter: Adrian Brock
>             Fix For: JBossMDR-2.2.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:12:59 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:12:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMDR-6) Test annotation
 overrides at the Invocation level in the metadata repository
Message-ID: <23827748.1245316379231.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin updated JBMDR-6:
----------------------------

    Fix Version/s: JBossMDR-2.2.0.Alpha1
                       (was: JBossMDR-2.0.2.GA)


> Test annotation overrides at the Invocation level in the metadata repository
> ----------------------------------------------------------------------------
>
>                 Key: JBMDR-6
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-6
>             Project: JBoss MetaData Repository
>          Issue Type: Sub-task
>          Components: Tests
>            Reporter: Adrian Brock
>             Fix For: JBossMDR-2.2.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:12:58 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:12:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMDR-59) Release JBoss MDR
	2.0.2.GA
In-Reply-To: <31196864.1245316378255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13371423.1245316378483.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBMDR-59.
------------------------------

    Resolution: Done


> Release JBoss MDR 2.0.2.GA
> --------------------------
>
>                 Key: JBMDR-59
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-59
>             Project: JBoss MetaData Repository
>          Issue Type: Release
>          Components: Release
>    Affects Versions: JBossMDR-2.0.1.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBossMDR-2.0.2.GA
>
>
> Release notes:
>  - https://jira.jboss.org/jira/secure/ReleaseNote.jspa?version=12312897&styleName=Text&projectId=12310561&Create=Create
> MVN repo:
>  - http://anonsvn.jboss.org/repos/repository.jboss.org/maven2/org/jboss/jboss-mdr/2.0.2.GA/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:17:57 2009
From: jira-events at lists.jboss.org (Jbm User (JIRA))
Date: Thu, 18 Jun 2009 05:17:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1660) journal files
 not getting cleaned up and server startup fails
Message-ID: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>

journal files not getting cleaned up and server startup fails
-------------------------------------------------------------

                 Key: JBMESSAGING-1660
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core Persistence
    Affects Versions: 2.0.0 Beta1
         Environment: Windows Vista SP1 32 bit, 2 GB RAM
            Reporter: Jbm User
            Assignee: Tim Fox


Hi,
I am using JBM 2.0.0.BETA1 stand alone server.
I have added 1 million messages in a queue with following page settings in jbm-configuration.xml

<paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
<global-page-size>10485760</global-page-size>

When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
Now, I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:19:56 2009
From: jira-events at lists.jboss.org (Jbm User (JIRA))
Date: Thu, 18 Jun 2009 05:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1660) journal files
 not getting cleaned up and server startup fails
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17912237.1245316796731.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jbm User updated JBMESSAGING-1660:
----------------------------------

    Description: 
Hi,
I am using JBM 2.0.0.BETA1 stand alone server.
I have added 1 million messages in a queue with following page settings in jbm-configuration.xml

<paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
<global-page-size>10485760</global-page-size>

When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

  was:
Hi,
I am using JBM 2.0.0.BETA1 stand alone server.
I have added 1 million messages in a queue with following page settings in jbm-configuration.xml

<paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
<global-page-size>10485760</global-page-size>

When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
Now, I am not sure why server is loading the journal files on start up when all the messages are already consumed. 



> journal files not getting cleaned up and server startup fails
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Tim Fox
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:36:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-104) Update 3rd party libs
 for JBCL 2.0.7.GA
Message-ID: <3825526.1245317816612.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update 3rd party libs for JBCL 2.0.7.GA
---------------------------------------

                 Key: JBCL-104
                 URL: https://jira.jboss.org/jira/browse/JBCL-104
             Project: JBoss ClassLoader
          Issue Type: Thirdparty Change
          Components: Release
    Affects Versions: JBossCL.2.0.6.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBossCL.2.0.7.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:38:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-105) Update
 classloading-spi to 5.1.0.SP1
Message-ID: <28998810.1245317936717.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update classloading-spi to 5.1.0.SP1
------------------------------------

                 Key: JBCL-105
                 URL: https://jira.jboss.org/jira/browse/JBCL-105
             Project: JBoss ClassLoader
          Issue Type: Component Upgrade
          Components: Dependencies
    Affects Versions: JBossCL.2.0.6.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBossCL.2.0.7.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:40:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-106) Update to
 jboss-common-core 2.2.14.GA
Message-ID: <10304120.1245318056456.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update to jboss-common-core 2.2.14.GA
-------------------------------------

                 Key: JBCL-106
                 URL: https://jira.jboss.org/jira/browse/JBCL-106
             Project: JBoss ClassLoader
          Issue Type: Component Upgrade
          Components: Dependencies
    Affects Versions: JBossCL.2.0.6.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBossCL.2.0.7.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:45:07 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:45:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-105) Update
 classloading-spi to 5.1.0.SP1
In-Reply-To: <28998810.1245317936717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32033064.1245318307913.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBCL-105.
------------------------------

    Resolution: Done


> Update classloading-spi to 5.1.0.SP1
> ------------------------------------
>
>                 Key: JBCL-105
>                 URL: https://jira.jboss.org/jira/browse/JBCL-105
>             Project: JBoss ClassLoader
>          Issue Type: Component Upgrade
>          Components: Dependencies
>    Affects Versions: JBossCL.2.0.6.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBossCL.2.0.7.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:04:57 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 06:04:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19634424.1245319497020.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson commented on JBWEB-142:
------------------------------------

Test Case:
1) Take heap with default configuration. Inspect org.apache.jasper.Constants and verify that DEFAULT_TAG_BUFFER_SIZE is 512. See attached default.png.
2) Add the following JVM option to run.conf:
 -Dorg.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE=1001
3) Take heap with default configuration. Inspect org.apache.jasper.Constants and verify that DEFAULT_TAG_BUFFER_SIZE is 1001. See attached set-to-1001.png.

> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-142.patch
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:07:07 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 06:07:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14181711.1245319627818.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-142:
-------------------------------

    Attachment: default.png


Screen shot from Eclipse Memory Analyzer Tool showing default org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE of 512.

> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: default.png, jbweb-142.patch, set-to-1001.png
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:07:08 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 06:07:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7241427.1245319628114.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-142:
-------------------------------

    Attachment: set-to-1001.png


Screen shot from Eclipse Memory Analyzer Tool showing org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE set to 1001 when -Dorg.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE=1001 JVM option used.

> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: default.png, jbweb-142.patch, set-to-1001.png
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:10:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 18 Jun 2009 06:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1660) journal
 files not getting cleaned up and server startup fails
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26653240.1245319856642.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox commented on JBMESSAGING-1660:
--------------------------------------

Hello jbm user-

Can you please attach some simple client code which we can run to replicate this problem, along with exact instructions for replication?

Thanks.

> journal files not getting cleaned up and server startup fails
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Tim Fox
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:29:08 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 06:29:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Parameterize
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21274052.1245320948445.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-142:
-------------------------------

    Summary: Parameterize org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE  (was: Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE)


> Parameterize org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> ----------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: default.png, jbweb-142.patch, set-to-1001.png
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:30:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 06:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBWEB-142) Parameterize
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27995159.1245321056912.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson reassigned JBWEB-142:
----------------------------------

    Assignee: Jean-Frederic Clere  (was: Remy Maucherat)


Since Remy is on vacation, can you please apply this upstream?

> Parameterize org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> ----------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Jean-Frederic Clere
>         Attachments: default.png, jbweb-142.patch, set-to-1001.png
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:35:56 2009
From: jira-events at lists.jboss.org (cristina gonzalez (JIRA))
Date: Thu, 18 Jun 2009 06:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1900) Task
 parent/child relationships support
In-Reply-To: <16282486.1229686014288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21429805.1245321356677.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

cristina gonzalez commented on JBRULES-1900:
--------------------------------------------

Hi Mauricio, I find what you posted really useful for what i am doing at the moment, but i am trying to get the files you uploaded and keeps saying they dont exist anymore, could you please upload them again so i can have a look at them please?

Thanks

Chrissie

> Task parent/child relationships support
> ---------------------------------------
>
>                 Key: JBRULES-1900
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1900
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (flow)
>    Affects Versions: 5.0.0.M1,  5.0.0.M2, 5.0.0.M3
>            Reporter: Mauricio Salatino
>            Assignee: Mauricio Salatino
>         Attachments: drools-process.rar, ParentChildRelationships.rar
>
>
> Support  for nested task inside a task in a ruleflow process. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:54:56 2009
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 18 Jun 2009 06:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-255)
 IdentityLoginModule
 Incomplete password-stacking useFirstPass implementation
In-Reply-To: <4221409.1214820452243.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21182225.1245322496580.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Darran Lofthouse commented on SECURITY-255:
-------------------------------------------

The following class is a modification I needed to use to get this to work: -

 https://svn.jboss.org/repos/jbossas/projects/security/security-negotiation/branches/SECURITY-141/jboss-negotiation-extras/src/main/java/org/jboss/security/negotiation/spnego/IdentityLoginModule.java


> IdentityLoginModule Incomplete password-stacking useFirstPass implementation
> ----------------------------------------------------------------------------
>
>                 Key: SECURITY-255
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-255
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.2.CR6
>            Reporter: Darran Lofthouse
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.4
>
>
> The IdentityLoginModule has got an incomplete useFirstPass implementation.
> The login() method does start with: -
>   if( super.login() == true )
>          return true;
> To skip login if useFirstPass is set and authentication has already occurred.
> However at the end of login() setting the principal in the shared state map should only happen if useFirstPass was set.  
> Also for this to work a credential also needs to be stored in the sharedStateMap otherwise other modules will assume authentication has not occurred.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:09:01 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-194) Update 3rd party
 libs for Deployers 2.0.8.GA
Message-ID: <25398580.1245323341009.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update 3rd party libs for Deployers 2.0.8.GA
--------------------------------------------

                 Key: JBDEPLOY-194
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-194
             Project: JBoss Deployers
          Issue Type: Thirdparty Change
          Components: release
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:13:07 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:13:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-195) Release JBoss
 Deployers 2.0.8.GA
Message-ID: <3551125.1245323587737.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release JBoss Deployers 2.0.8.GA
--------------------------------

                 Key: JBDEPLOY-195
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-195
             Project: JBoss Deployers
          Issue Type: Release
          Components: release
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA


Release notes:
 - https://jira.jboss.org/jira/secure/ReleaseNote.jspa?version=12313669&styleName=Text&projectId=12310581&Create=Create

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:14:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-196) Update JBoss Man
	to 2.1.1.CR1
Message-ID: <6724157.1245323696453.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update JBoss Man to 2.1.1.CR1
-----------------------------

                 Key: JBDEPLOY-196
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-196
             Project: JBoss Deployers
          Issue Type: Component Upgrade
          Components: release
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:16:57 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-198) Update JBoss
 Kernel to 2.0.7.GA
Message-ID: <25985562.1245323817213.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update JBoss Kernel to 2.0.7.GA
-------------------------------

                 Key: JBDEPLOY-198
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-198
             Project: JBoss Deployers
          Issue Type: Component Upgrade
          Components: release
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:16:58 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:16:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-199) Update
 classloading-spi to 5.1.0.SP1
Message-ID: <9719728.1245323818486.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update classloading-spi to 5.1.0.SP1
------------------------------------

                 Key: JBDEPLOY-199
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-199
             Project: JBoss Deployers
          Issue Type: Component Upgrade
          Components: release
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:18:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-200) Update to
 jboss-common-core 2.2.14.GA
Message-ID: <14716024.1245323936498.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update to jboss-common-core 2.2.14.GA
-------------------------------------

                 Key: JBDEPLOY-200
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-200
             Project: JBoss Deployers
          Issue Type: Component Upgrade
          Components: release
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:22:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-107) Update JBoss Man to
	2.1.1.CR1
Message-ID: <19043462.1245324176682.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update JBoss Man to 2.1.1.CR1
-----------------------------

                 Key: JBCL-107
                 URL: https://jira.jboss.org/jira/browse/JBCL-107
             Project: JBoss ClassLoader
          Issue Type: Component Upgrade
          Components: Dependencies
    Affects Versions: JBossCL.2.0.6.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBossCL.2.0.7.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:22:58 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:22:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-108) Update JBoss Kernel
	to 2.0.7.GA
Message-ID: <7320847.1245324178625.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update JBoss Kernel to 2.0.7.GA
-------------------------------

                 Key: JBCL-108
                 URL: https://jira.jboss.org/jira/browse/JBCL-108
             Project: JBoss ClassLoader
          Issue Type: Component Upgrade
          Components: Dependencies
    Affects Versions: JBossCL.2.0.6.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBossCL.2.0.7.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:24:58 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:24:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-107) Update JBoss Man to
	2.1.1.CR1
In-Reply-To: <19043462.1245324176682.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27247324.1245324298642.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBCL-107.
------------------------------

    Resolution: Done


> Update JBoss Man to 2.1.1.CR1
> -----------------------------
>
>                 Key: JBCL-107
>                 URL: https://jira.jboss.org/jira/browse/JBCL-107
>             Project: JBoss ClassLoader
>          Issue Type: Component Upgrade
>          Components: Dependencies
>    Affects Versions: JBossCL.2.0.6.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBossCL.2.0.7.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:36:56 2009
From: jira-events at lists.jboss.org (Mauricio Salatino (JIRA))
Date: Thu, 18 Jun 2009 07:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1900) Task
 parent/child relationships support
In-Reply-To: <16282486.1229686014288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23412413.1245325016568.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mauricio Salatino commented on JBRULES-1900:
--------------------------------------------

Hi Cristina,
This code is already on the trunk and in the final release of Drools 5.
Thanks

> Task parent/child relationships support
> ---------------------------------------
>
>                 Key: JBRULES-1900
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1900
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (flow)
>    Affects Versions: 5.0.0.M1,  5.0.0.M2, 5.0.0.M3
>            Reporter: Mauricio Salatino
>            Assignee: Mauricio Salatino
>         Attachments: drools-process.rar, ParentChildRelationships.rar
>
>
> Support  for nested task inside a task in a ruleflow process. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:02:57 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 08:02:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-199) Update
 classloading-spi to 5.1.0.SP1
In-Reply-To: <9719728.1245323818486.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15072337.1245326577502.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBDEPLOY-199.
----------------------------------

    Resolution: Done


> Update classloading-spi to 5.1.0.SP1
> ------------------------------------
>
>                 Key: JBDEPLOY-199
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-199
>             Project: JBoss Deployers
>          Issue Type: Component Upgrade
>          Components: release
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:02:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 08:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-196) Update JBoss Man
	to 2.1.1.CR1
In-Reply-To: <6724157.1245323696453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25909901.1245326576718.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBDEPLOY-196.
----------------------------------

    Resolution: Done


> Update JBoss Man to 2.1.1.CR1
> -----------------------------
>
>                 Key: JBDEPLOY-196
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-196
>             Project: JBoss Deployers
>          Issue Type: Component Upgrade
>          Components: release
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:02:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 08:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-197) Update JBoss MDR
	to 2.0.2.GA
In-Reply-To: <12941831.1245323696903.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29959472.1245326576880.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBDEPLOY-197.
----------------------------------

    Resolution: Done


> Update JBoss MDR to 2.0.2.GA
> ----------------------------
>
>                 Key: JBDEPLOY-197
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-197
>             Project: JBoss Deployers
>          Issue Type: Component Upgrade
>          Components: release
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:02:57 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 08:02:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-200) Update to
 jboss-common-core 2.2.14.GA
In-Reply-To: <14716024.1245323936498.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22526332.1245326577716.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBDEPLOY-200.
----------------------------------

    Resolution: Done


> Update to jboss-common-core 2.2.14.GA
> -------------------------------------
>
>                 Key: JBDEPLOY-200
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-200
>             Project: JBoss Deployers
>          Issue Type: Component Upgrade
>          Components: release
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:02:57 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 08:02:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-198) Update JBoss
 Kernel to 2.0.7.GA
In-Reply-To: <25985562.1245323817213.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15468785.1245326577067.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBDEPLOY-198.
----------------------------------

    Resolution: Done


> Update JBoss Kernel to 2.0.7.GA
> -------------------------------
>
>                 Key: JBDEPLOY-198
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-198
>             Project: JBoss Deployers
>          Issue Type: Component Upgrade
>          Components: release
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:08:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 08:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-194) Update 3rd party
 libs for Deployers 2.0.8.GA
In-Reply-To: <25398580.1245323341009.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24406430.1245326936683.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBDEPLOY-194.
----------------------------------

    Resolution: Done


> Update 3rd party libs for Deployers 2.0.8.GA
> --------------------------------------------
>
>                 Key: JBDEPLOY-194
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-194
>             Project: JBoss Deployers
>          Issue Type: Thirdparty Change
>          Components: release
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:10:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 08:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-195) Release JBoss
 Deployers 2.0.8.GA
In-Reply-To: <3551125.1245323587737.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11636934.1245327056935.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBDEPLOY-195.
----------------------------------

    Resolution: Done


> Release JBoss Deployers 2.0.8.GA
> --------------------------------
>
>                 Key: JBDEPLOY-195
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-195
>             Project: JBoss Deployers
>          Issue Type: Release
>          Components: release
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>
> Release notes:
>  - https://jira.jboss.org/jira/secure/ReleaseNote.jspa?version=12313669&styleName=Text&projectId=12310581&Create=Create

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 09:02:00 2009
From: jira-events at lists.jboss.org (Jbm User (JIRA))
Date: Thu, 18 Jun 2009 09:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1660) journal files
 not getting cleaned up and server startup fails
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13004560.1245330120720.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jbm User updated JBMESSAGING-1660:
----------------------------------

    Attachment: src.zip
                jbm-configuration.xml
                jbm-jms.xml


Hi Tim,
Thank you for the prompt response. Attached is the client code I am using. I have had this issue a few times yesterday and this morning but unfortunately I am not able to reproduce the issue now. However, I am able to reproduce it when I perform following steps. Hope it helps

1) Start server (I am using the server instance provided in messaging-2.0.0.BETA1\bin). Config files are attached
2) Run JMSSender.java to send 1 million messages and let it complete
3) Run JMSConsumer.java and while it is running (say after consuming 100000 messages), terminate server
4) JMSConsumer will detect that the connection is closed and will exit in 1 minute
5) Start the server
6) Run JMSConsumer.java again.
7) Observe that the number of journal files keep on increasing while the messages are being consumed.
8) Let the JMSConsumer complete (exits automatically 1 minute after consuming all the messages)
9) Observe that the paging folder is empty (except for address.txt file) and journal folder still has number of files
10) Try to restart the server and observe that it fails with java.lang.OutOfMemoryError

Thank You

> journal files not getting cleaned up and server startup fails
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Tim Fox
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 09:05:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 18 Jun 2009 09:05:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1660) journal
 files not getting cleaned up and server startup fails
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28532481.1245330357621.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox reassigned JBMESSAGING-1660:
------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)


> journal files not getting cleaned up and server startup fails
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 09:36:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 09:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20055513.1245332216895.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson reassigned JBWEB-144:
----------------------------------

    Assignee: Jean-Frederic Clere  (was: Remy Maucherat)


> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Jean-Frederic Clere
>         Attachments: jbweb-144.patch, test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 09:52:58 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Thu, 18 Jun 2009 09:52:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15390224.1245333178552.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Charles Crouch updated JBAS-6185:
---------------------------------

    Assignee: Jason T. Greene  (was: Dimitris Andreadis)
    Priority: Blocker  (was: Major)


> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Jason T. Greene
>            Priority: Blocker
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 09:56:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 09:56:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28285840.1245333417956.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic commented on JBMESSAGING-1658:
----------------------------------------------

>From this message:

13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f


And this message:

14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl] A connection has been made to the backup server so it will be activated! This



It seems there was a client failing into the backup?

> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 09:58:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 09:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24977076.1245333536981.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic commented on JBMESSAGING-1658:
----------------------------------------------

what I was asking was.. .maybe Scott also had clients on his scenario. Not just the server sitting alone?

> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:01:04 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Thu, 18 Jun 2009 10:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4591608.1245333664106.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Charles Crouch commented on JBAS-6185:
--------------------------------------

There are customers who want to see jboss and jvm mbeans collocated in the same mbeanserver so that JON can monitor them, (jboss.platform.mbeanserver) but also want remote jmx enabled so they can connect directly to an instance with jconsole (com.sun.jmxremote.port=???). However enabling both of these at the same time no longer seems possible.

> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Jason T. Greene
>            Priority: Blocker
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:04:59 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 18 Jun 2009 10:04:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6943) jboss threads
 metadata missing propOrder
In-Reply-To: <11303033.1242746411360.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31420966.1245333899507.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

David Lloyd updated JBAS-6943:
------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1


> jboss threads metadata missing propOrder
> ----------------------------------------
>
>                 Key: JBAS-6943
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6943
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Alexey Loubyansky
>            Assignee: David Lloyd
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfsfile:/C:/Users/avoka/svn.jboss.org/jbossas/Branch_5_x/build/output/jboss-5.1.0.GA/server/default/deploy/xnio-provider.jar/
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:362)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:322)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:294)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.deploy(AbstractParsingDeployerWithOutput.java:234)
> 	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.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(Unknown Source)
> Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Property order is not specified for type org.jboss.threads.metadata.ThreadsMetaData bound to a sequence. Property order can be specified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: threadPoolExecutors threadFactories scheduledThreadPoolExecutors threadGroups notatingExecutors directExecutors
> at org.jboss.threads.metadata.ThreadsMetaData
> 	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)
> 	at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:168)
> 	at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:189)
> 	at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:166)
> 	at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:137)
> 	at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:121)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:239)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:355)
> 	... 33 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:04:58 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 18 Jun 2009 10:04:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1324080.1245333898255.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox commented on JBMESSAGING-1658:
--------------------------------------

Yes, clebert I think you are right.

You would only get this message:

14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl] A connection has been made to the backup server so it will be activated! This 

if a client program attempted to make a connection directly to the backup server or failed over from live to backup, so there must be more things going on here than just two idle servers.

> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:09:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 10:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4405797.1245334196711.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson commented on JBWEB-144:
------------------------------------

Solution decided is to rebase org.apache.el to 6.0.20.

> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Jean-Frederic Clere
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:11:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 18 Jun 2009 10:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7038) Track component
 update - 5.2.0.Beta1
Message-ID: <2791010.1245334316593.JavaMail.jira@cloud.prod.atl2.jboss.com>

Track component update - 5.2.0.Beta1
------------------------------------

                 Key: JBAS-7038
                 URL: https://jira.jboss.org/jira/browse/JBAS-7038
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Other
            Reporter: Jason T. Greene
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:15:59 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 18 Jun 2009 10:15:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24953999.1245334559268.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene reassigned JBAS-6185:
-------------------------------------

    Assignee: Shelly McGowan  (was: Jason T. Greene)


Shelly, could you take a look at this one?

> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Shelly McGowan
>            Priority: Blocker
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:58:58 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 18 Jun 2009 10:58:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7037) JBossAS 5.x fails to
 use EJB's
 security domain in jboss.xml when the call is from web container
In-Reply-To: <2821553.1245299576703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2609508.1245337138664.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated JBAS-7037:
--------------------------------

    Assignee: Stefan Guilhen  (was: Anil Saldhana)
    Priority: Major  (was: Critical)


Stefan,  take an initial look at this case in the next few days.

> JBossAS 5.x fails to use EJB's security domain in jboss.xml when the call is from web container
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7037
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: Problem found on Windows platform
>            Reporter: Calvin Lin
>            Assignee: Stefan Guilhen
>         Attachments: JBAS-jira-authenBug.zip
>
>
> A degredation from JBoss 4.0.x and 4.2.x to JBoss 5.0.1.GA and JBoss 5.1.0.GA.
> We noticed that the JAAS login in EJB container always picks up the Web app's security domain when the client login is originated from a web application client.  The security domain specified in EJB container's jboss.xml is always ignored in this situation.
> The detailed problem description is posted on JBoss forum:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156863

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 11:00:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 18 Jun 2009 11:00:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7037) JBossAS 5.x fails to
 use EJB's
 security domain in jboss.xml when the call is from web container
In-Reply-To: <2821553.1245299576703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24171479.1245337256646.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated JBAS-7037:
--------------------------------

    Fix Version/s: JBossAS-5.0.2.GA


Maybe a metadata merge issue.

> JBossAS 5.x fails to use EJB's security domain in jboss.xml when the call is from web container
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7037
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: Problem found on Windows platform
>            Reporter: Calvin Lin
>            Assignee: Stefan Guilhen
>             Fix For: JBossAS-5.0.2.GA
>
>         Attachments: JBAS-jira-authenBug.zip
>
>
> A degredation from JBoss 4.0.x and 4.2.x to JBoss 5.0.1.GA and JBoss 5.1.0.GA.
> We noticed that the JAAS login in EJB container always picks up the Web app's security domain when the client login is originated from a web application client.  The security domain specified in EJB container's jboss.xml is always ignored in this situation.
> The detailed problem description is posted on JBoss forum:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156863

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 11:11:58 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 18 Jun 2009 11:11:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20706048.1245337918892.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox closed JBMESSAGING-1658.
--------------------------------

    Resolution: Rejected


Closed on reporters request.

> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 11:23:57 2009
From: jira-events at lists.jboss.org (Joshua Davis (JIRA))
Date: Thu, 18 Jun 2009 11:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-56) Add tests that
 bootstraps are shutdown in reverse order from start
In-Reply-To: <30621135.1240858006745.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32689544.1245338637257.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Joshua Davis updated JBBOOT-56:
-------------------------------

    Attachment: JBBOOT-56.v1.patch


Here's my first attempt at a test for this.   Notes:
1) I put it in jboss-bootstrap-impl-mc.  Not sure which module was the right one.
2) There three urls in the bootstrap.  Each one defines one instance of a test POJO.
3) Extracted the code that gets a bean from the MC by name into a helper.   More code than I expected.
4) Found that the MC 'cleans up' properties that were set in the bean XML at shutdown.   Wow... That's squeaky clean.


> Add tests that bootstraps are shutdown in reverse order from start
> ------------------------------------------------------------------
>
>                 Key: JBBOOT-56
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-56
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-base
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: Unscheduled
>
>         Attachments: JBBOOT-56.v1.patch
>
>
> Ensure that we are shutting down in proper sequence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 11:26:07 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 18 Jun 2009 11:26:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7019) Fork the existing
 tomcat integration code from AS into Spider
In-Reply-To: <22128270.1245060656840.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7266944.1245338767418.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf resolved JBAS-7019.
---------------------------------

    Resolution: Done


> Fork the existing tomcat integration code from AS into Spider
> -------------------------------------------------------------
>
>                 Key: JBAS-7019
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7019
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 11:59:10 2009
From: jira-events at lists.jboss.org (Jonathon Leibundguth (JIRA))
Date: Thu, 18 Jun 2009 11:59:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2125) Drools core
 multithreading issue
In-Reply-To: <26229278.1245145676528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26572824.1245340750182.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jonathon Leibundguth commented on JBRULES-2125:
-----------------------------------------------

Think I've found something similar, but wasn't sure whether to add as a new issue - I had believed it might be the same as 2114, possibly like this one, however, it may be unique.  I don't currently have a unit test for this, we would have too much code to upload to show it right now -- but detected deadlock was using jconsole between 3 threads:

thread 1, called "droolsFireUntilHalt" is attempting to expire an object/fact while running fireUntilHalt()

thread 2, called "pool-2-thread-1", is an internal drools thread and its running a timer (defined in a .rf file) that injects a fact every 2 seconds to kick off rules -- it blocks on that insert() on working memory

thread 3, called "jpCapSensorThread", is inserting objects into a stream / named entry point - it also blocks on insert(), this time on a named entry point.

Below are the traces from these threads:

Name: droolsFireUntilHalt
State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync at 1def658 owned by: jpCapSensorThread
Total blocked: 293  Total waited: 293

Stack trace: 
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
org.drools.common.NamedEntryPoint.retract(NamedEntryPoint.java:258)
org.drools.common.NamedEntryPoint.retract(NamedEntryPoint.java:245)
org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteExpireAction.execute(ReteooWorkingMemory.java:350)
org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1486)
   - locked java.util.LinkedList at e707bb
org.drools.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1067)
org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:701)
   - locked org.drools.reteoo.ReteooStatefulSession at 14fa79d
org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:678)
   - locked org.drools.reteoo.ReteooStatefulSession at 14fa79d
org.drools.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:195)

---------

Name: pool-2-thread-1
State: BLOCKED on java.util.LinkedList at e707bb owned by: droolsFireUntilHalt
Total blocked: 1  Total waited: 296

Stack trace: 
org.drools.common.AbstractWorkingMemory.queueWorkingMemoryAction(AbstractWorkingMemory.java:1509)
org.drools.reteoo.ObjectTypeNode$ExpireJob.execute(ObjectTypeNode.java:443)
org.drools.time.impl.JDKTimerService$JDKCallableJob.call(JDKTimerService.java:132)
org.drools.time.impl.JDKTimerService$JDKCallableJob.call(JDKTimerService.java:110)
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
java.util.concurrent.FutureTask.run(FutureTask.java:138)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:619)

--------

Name: jpCapSensorThread
State: BLOCKED on java.util.LinkedList at e707bb owned by: droolsFireUntilHalt
Total blocked: 4  Total waited: 0

Stack trace: 
org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1479)
org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:158)
org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:122)
org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:80)
org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:28)
com.raytheon.nsff.spi.jpcap.DNSPacketInjector.receivePacket(DNSPacketInjector.java:23)
jpcap.JpcapCaptor.loopPacket(Native Method)
com.raytheon.nsff.spi.jpcap.JPCapSPIImpl$1.run(JPCapSPIImpl.java:98)
java.lang.Thread.run(Thread.java:619)



> Drools core multithreading issue
> --------------------------------
>
>                 Key: JBRULES-2125
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2125
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: Java HotSpot v 1.6.0_06, WinXP SP3
>            Reporter: Andrey Nechaev
>            Assignee: Edson Tirelli
>         Attachments: Main.java
>
>
> Attachement below is the code showing the problems. 
> The program hangs and nothing is displayed in the Console.
> If I put lines 10-11 before the line 6, I get a NullPointerException:
> Exception in thread "main" java.lang.NullPointerException
>             at org.drools.reteoo.ObjectSource.addObjectSink(ObjectSource.java:124)
> ...
> But, if I comment out the lines 2&3, everything works ok.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 12:07:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 12:07:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1660) journal
 files not getting cleaned up and server startup fails
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5396639.1245341277550.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic commented on JBMESSAGING-1660:
----------------------------------------------

Thanks for the testcase.

I could replicate the issue, and I' m working on a fix now.

It looks like something related to reloading DuplicateIDCacheImpl. I' m investigating it now.

> journal files not getting cleaned up and server startup fails
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 12:38:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 18 Jun 2009 12:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-90)
 PropertiesCompositeObjectNameMetaMapper uses invalid domain
Message-ID: <17256746.1245343136516.JavaMail.jira@cloud.prod.atl2.jboss.com>

PropertiesCompositeObjectNameMetaMapper uses invalid domain
-----------------------------------------------------------

                 Key: JBMAN-90
                 URL: https://jira.jboss.org/jira/browse/JBMAN-90
             Project: JBoss Managed
          Issue Type: Bug
          Components: metatype
    Affects Versions: JBossMan.2.1.1.Beta3
            Reporter: Brian Stansberry


Problem is in last line below:

public ObjectName unwrapMetaValue(MetaValue metaValue)
   {
      CompositeValue compositeValue = (CompositeValue) metaValue;
      SimpleValue domain = (SimpleValue) compositeValue.get("domain");
      String domainUnwrap = domain.toString();

Results in:

javax.management.MalformedObjectNameException: Invalid domain: SimpleMetaType:java.lang.String:jgroups

Needs to be:

String domainUnwrap = (String) domain.getValue();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 12:48:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 18 Jun 2009 12:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6960) once a Topic or
 Queue has been
 stopped via the 'stop' operation, none of its operations or properties
 work, and thus it cannot be restarted using the 'start' operation
In-Reply-To: <11989891.1242832445240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32707279.1245343736754.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Emanuel Muckenhuber resolved JBAS-6960.
---------------------------------------

    Resolution: Done


> once a Topic or Queue has been stopped via the 'stop' operation, none of its operations or properties work, and thus it cannot be restarted using the 'start' operation
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6960
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6960
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Ian Springer
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:10:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMDR-58) Update to
 jboss-common-core 2.2.14.GA
In-Reply-To: <5995551.1245316256601.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3418765.1245316256796.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBMDR-58.
------------------------------

    Resolution: Done


> Update to jboss-common-core 2.2.14.GA
> -------------------------------------
>
>                 Key: JBMDR-58
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-58
>             Project: JBoss MetaData Repository
>          Issue Type: Thirdparty Change
>          Components: Release
>    Affects Versions: JBossMDR-2.0.1.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBossMDR-2.0.2.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:12:58 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:12:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMDR-7) Test annotation
 overrides at
 deployment time don't pick up thread and invocation level
Message-ID: <28575849.1245316378868.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin updated JBMDR-7:
----------------------------

    Fix Version/s: JBossMDR-2.2.0.Alpha1
                       (was: JBossMDR-2.0.2.GA)


> Test annotation overrides at deployment time don't pick up thread and invocation level
> --------------------------------------------------------------------------------------
>
>                 Key: JBMDR-7
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-7
>             Project: JBoss MetaData Repository
>          Issue Type: Sub-task
>          Components: Tests
>            Reporter: Adrian Brock
>             Fix For: JBossMDR-2.2.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:45:07 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:45:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-106) Update to
 jboss-common-core 2.2.14.GA
In-Reply-To: <10304120.1245318056456.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5672415.1245318307622.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBCL-106.
------------------------------

    Resolution: Done


> Update to jboss-common-core 2.2.14.GA
> -------------------------------------
>
>                 Key: JBCL-106
>                 URL: https://jira.jboss.org/jira/browse/JBCL-106
>             Project: JBoss ClassLoader
>          Issue Type: Component Upgrade
>          Components: Dependencies
>    Affects Versions: JBossCL.2.0.6.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBossCL.2.0.7.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 14:17:56 2009
From: jira-events at lists.jboss.org (John Gilbert (JIRA))
Date: Thu, 18 Jun 2009 14:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
Message-ID: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>

ejb-jar.xml <interceptor-order> not supported
---------------------------------------------

                 Key: EJBTHREE-1852
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
             Project: EJB 3.0
          Issue Type: Bug
          Components: deployers, ejb3, interceptors
    Affects Versions: 1.1.5
            Reporter: John Gilbert


The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.

Caused by: java.lang.NullPointerException
        at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
        at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
        at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
        at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
        at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
        at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
        at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)



   <assembly-descriptor>
      <interceptor-binding>
         <ejb-name>*</ejb-name>
            <interceptor-order>
         	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
         	<interceptor-class>my.CustomInterceptor</interceptor-class>
            </interceptor-order>
      </interceptor-binding>
   </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 13:38:09 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 18 Jun 2009 13:38:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2128) Change the
 drools.rulebaseUpdateHandler property to default to none
Message-ID: <33524274.1245346689053.JavaMail.jira@cloud.prod.atl2.jboss.com>

Change the drools.rulebaseUpdateHandler property to default to none
-------------------------------------------------------------------

                 Key: JBRULES-2128
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2128
             Project: JBoss Drools
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: drools-api, drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


Change the drools.rulebaseUpdateHandler property to default to none

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 13:47:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 18 Jun 2009 13:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMAN-90)
 PropertiesCompositeObjectNameMetaMapper uses invalid domain
In-Reply-To: <17256746.1245343136516.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9676497.1245347276517.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry closed JBMAN-90.
---------------------------------

    Fix Version/s: JBossMan.2.1.1.CR1
       Resolution: Done


> PropertiesCompositeObjectNameMetaMapper uses invalid domain
> -----------------------------------------------------------
>
>                 Key: JBMAN-90
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-90
>             Project: JBoss Managed
>          Issue Type: Bug
>          Components: metatype
>    Affects Versions: JBossMan.2.1.1.Beta3
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossMan.2.1.1.CR1
>
>
> Problem is in last line below:
> public ObjectName unwrapMetaValue(MetaValue metaValue)
>    {
>       CompositeValue compositeValue = (CompositeValue) metaValue;
>       SimpleValue domain = (SimpleValue) compositeValue.get("domain");
>       String domainUnwrap = domain.toString();
> Results in:
> javax.management.MalformedObjectNameException: Invalid domain: SimpleMetaType:java.lang.String:jgroups
> Needs to be:
> String domainUnwrap = (String) domain.getValue();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 14:45:37 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Thu, 18 Jun 2009 14:45:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7039) Allow IBM
 PKCS11IMPLKS to be used with JaasSecurityDomain
In-Reply-To: <14671838.1245350048812.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9449547.1245350737130.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Marcus Moyses resolved JBAS-7039.
---------------------------------

    Resolution: Done


Modified code to work with IBM's implementation as well.

> Allow IBM PKCS11IMPLKS to be used with JaasSecurityDomain
> ---------------------------------------------------------
>
>                 Key: JBAS-7039
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7039
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Must add a feature to work with both PKCS11 and PKCS11IMPLKS keystore types in JaasSecurityDomain.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 14:45:36 2009
From: jira-events at lists.jboss.org (John Gilbert (JIRA))
Date: Thu, 18 Jun 2009 14:45:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11500264.1245350736909.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472844#action_12472844 ] 

John Gilbert commented on EJBTHREE-1852:
----------------------------------------

this works fine in AS 4.2.3, but not when I switch to AS 5.1.

> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: deployers, ejb3, interceptors
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 13:38:08 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 18 Jun 2009 13:38:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMAN-90)
 PropertiesCompositeObjectNameMetaMapper uses invalid domain
In-Reply-To: <17256746.1245343136516.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30767253.1245346688730.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry reassigned JBMAN-90:
-------------------------------------

    Assignee: Brian Stansberry


> PropertiesCompositeObjectNameMetaMapper uses invalid domain
> -----------------------------------------------------------
>
>                 Key: JBMAN-90
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-90
>             Project: JBoss Managed
>          Issue Type: Bug
>          Components: metatype
>    Affects Versions: JBossMan.2.1.1.Beta3
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> Problem is in last line below:
> public ObjectName unwrapMetaValue(MetaValue metaValue)
>    {
>       CompositeValue compositeValue = (CompositeValue) metaValue;
>       SimpleValue domain = (SimpleValue) compositeValue.get("domain");
>       String domainUnwrap = domain.toString();
> Results in:
> javax.management.MalformedObjectNameException: Invalid domain: SimpleMetaType:java.lang.String:jgroups
> Needs to be:
> String domainUnwrap = (String) domain.getValue();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 16:13:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 16:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1660)
 DuplicateIDCacheImpl won't delete records after reload
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30086943.1245356036815.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic updated JBMESSAGING-1660:
-----------------------------------------

        Fix Version/s: 2.0.0
    Affects Version/s: 2.0.0.beta2


> DuplicateIDCacheImpl won't delete records after reload
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 15:56:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 15:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1660)
 DuplicateIDCacheImpl won't delete records after reload
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <466852.1245355016948.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic updated JBMESSAGING-1660:
-----------------------------------------

    Summary: DuplicateIDCacheImpl won't delete records after reload  (was: journal files not getting cleaned up and server startup fails)


I have replicated the issue.

DuplicateCacheImpl position is out of sync after reload. 

It should be fixed soon.

> DuplicateIDCacheImpl won't delete records after reload
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 16:13:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 16:13:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1660)
 DuplicateIDCacheImpl won't delete records after reload
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12972943.1245356037190.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic closed JBMESSAGING-1660.
----------------------------------------

    Resolution: Done


Thanks for the report.

It's fixed on trunk now

> DuplicateIDCacheImpl won't delete records after reload
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:08:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-190) Fix
	TreeStructureCache
In-Reply-To: <5441871.1244481116496.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14860229.1245323337449.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBDEPLOY-190.
----------------------------------

    Resolution: Done


> Fix TreeStructureCache
> ----------------------
>
>                 Key: JBDEPLOY-190
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-190
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: structure
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>
> TreeStructureCache shows strange leaves in MC demos.
> e.g. node's names do not equal to node's children; empty names vs. 2 children

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:14:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-197) Update JBoss MDR
	to 2.0.2.GA
Message-ID: <12941831.1245323696903.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update JBoss MDR to 2.0.2.GA
----------------------------

                 Key: JBDEPLOY-197
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-197
             Project: JBoss Deployers
          Issue Type: Component Upgrade
          Components: release
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:24:58 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:24:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-108) Update JBoss Kernel
	to 2.0.7.GA
In-Reply-To: <7320847.1245324178625.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28974789.1245324298445.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ales Justin resolved JBCL-108.
------------------------------

    Resolution: Done


> Update JBoss Kernel to 2.0.7.GA
> -------------------------------
>
>                 Key: JBCL-108
>                 URL: https://jira.jboss.org/jira/browse/JBCL-108
>             Project: JBoss ClassLoader
>          Issue Type: Component Upgrade
>          Components: Dependencies
>    Affects Versions: JBossCL.2.0.6.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBossCL.2.0.7.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 13:44:05 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 18 Jun 2009 13:44:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2128) Change the
 drools.rulebaseUpdateHandler property to default to none
In-Reply-To: <33524274.1245346689053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20865340.1245347045980.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli closed JBRULES-2128.
----------------------------------

    Resolution: Done


Done.

> Change the drools.rulebaseUpdateHandler property to default to none
> -------------------------------------------------------------------
>
>                 Key: JBRULES-2128
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2128
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-api, drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> Change the drools.rulebaseUpdateHandler property to default to none

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 14:34:08 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Thu, 18 Jun 2009 14:34:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7039) Allow IBM
 PKCS11IMPLKS to be used with JaasSecurityDomain
Message-ID: <14671838.1245350048812.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow IBM PKCS11IMPLKS to be used with JaasSecurityDomain
---------------------------------------------------------

                 Key: JBAS-7039
                 URL: https://jira.jboss.org/jira/browse/JBAS-7039
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Marcus Moyses
            Assignee: Marcus Moyses
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


Must add a feature to work with both PKCS11 and PKCS11IMPLKS keystore types in JaasSecurityDomain.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:33:56 2009
From: jira-events at lists.jboss.org (cristina gonzalez (JIRA))
Date: Thu, 18 Jun 2009 08:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1900) Task
 parent/child relationships support
In-Reply-To: <16282486.1229686014288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28823282.1245328436659.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

cristina gonzalez commented on JBRULES-1900:
--------------------------------------------

Ohh thanks Mauricio.

> Task parent/child relationships support
> ---------------------------------------
>
>                 Key: JBRULES-1900
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1900
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (flow)
>    Affects Versions: 5.0.0.M1,  5.0.0.M2, 5.0.0.M3
>            Reporter: Mauricio Salatino
>            Assignee: Mauricio Salatino
>         Attachments: drools-process.rar, ParentChildRelationships.rar
>
>
> Support  for nested task inside a task in a ruleflow process. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 09:07:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 18 Jun 2009 09:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-255)
 IdentityLoginModule Incomplete
 password-stacking useFirstPass implementation
In-Reply-To: <4221409.1214820452243.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24610936.1245330476453.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana updated SECURITY-255:
-----------------------------------

      Component/s: Negotiation
                       (was: JBossSX)
    Fix Version/s: Negotiation_2.0.4.GA
                       (was: JBossSecurity_2.0.4)
         Assignee: Darran Lofthouse  (was: Anil Saldhana)


> IdentityLoginModule Incomplete password-stacking useFirstPass implementation
> ----------------------------------------------------------------------------
>
>                 Key: SECURITY-255
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-255
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: 2.0.2.CR6
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2.0.4.GA
>
>
> The IdentityLoginModule has got an incomplete useFirstPass implementation.
> The login() method does start with: -
>   if( super.login() == true )
>          return true;
> To skip login if useFirstPass is set and authentication has already occurred.
> However at the end of login() setting the principal in the shared state map should only happen if useFirstPass was set.  
> Also for this to work a credential also needs to be stored in the sharedStateMap otherwise other modules will assume authentication has not occurred.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:07:57 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 10:07:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9490112.1245334077059.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Mike Millson updated JBWEB-144:
-------------------------------

    Attachment:     (was: jbweb-144.patch)


> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Jean-Frederic Clere
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 14:38:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 18 Jun 2009 14:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <11919252.1245350336801.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan reassigned JBAS-7032:
------------------------------------

    Assignee: Shelly McGowan  (was: Scott Marlow)


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 17:08:57 2009
From: jira-events at lists.jboss.org (Peter Crossley (JIRA))
Date: Thu, 18 Jun 2009 17:08:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1661) Messages in
 JBoss 5.1 that
 use bridging get stuck in a devlivering mode and are not sent to the remote
 cluster
Message-ID: <29236051.1245359337536.JavaMail.jira@cloud.prod.atl2.jboss.com>

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://jira.jboss.org/jira/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: Tim Fox
             Fix For: 1.4.4.GA


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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 17:46:58 2009
From: jira-events at lists.jboss.org (Jim Brownfield (JIRA))
Date: Thu, 18 Jun 2009 17:46:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6499)
 jboss.tomcat.connectors.started JMX Notification Missing
In-Reply-To: <12599125.1234469879130.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20153924.1245361618932.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jim Brownfield commented on JBAS-6499:
--------------------------------------

As far as I can tell, just uncommenting the sendNotification fixes this.  I don't know if there are other possible implications to doing that.  Do you want me to fix it?  If so, what do I need to do to get permission?  Thanks.

> jboss.tomcat.connectors.started JMX Notification Missing
> --------------------------------------------------------
>
>                 Key: JBAS-6499
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6499
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.0.GA
>            Reporter: Jim Brownfield
>            Assignee: Remy Maucherat
>
> It appears the jboss.tomcat.connectors.started JMX notification is missing in JBoss 5.0.0.  Looking through the JBoss source code, the TOMCAT_CONNECTORS_STARTED is the static variable containing the message.  That variable seems to only be referenced in org.jboss.web.tomcat.service.deployers.TomcatService.java in a comment within the method startConnectors():
>       /*
>        * TODO: // Notify listeners that connectors have started processing requests sendNotification(new
>        * Notification(TOMCAT_CONNECTORS_STARTED, this, getNextNotificationSequenceNumber()));
>        */

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 18:32:56 2009
From: jira-events at lists.jboss.org (Calvin Lin (JIRA))
Date: Thu, 18 Jun 2009 18:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7037) JBossAS 5.x fails to
 use EJB's
 security domain in jboss.xml when the call is from web container
In-Reply-To: <2821553.1245299576703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2595905.1245364376584.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Calvin Lin updated JBAS-7037:
-----------------------------

    Attachment: ConfigFiles-lib.zip


Additional files needed in JBoss AS directory for testing.
Please read the readme.txt file for details.

> JBossAS 5.x fails to use EJB's security domain in jboss.xml when the call is from web container
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7037
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: Problem found on Windows platform
>            Reporter: Calvin Lin
>            Assignee: Stefan Guilhen
>             Fix For: JBossAS-5.0.2.GA
>
>         Attachments: ConfigFiles-lib.zip, JBAS-jira-authenBug.zip
>
>
> A degredation from JBoss 4.0.x and 4.2.x to JBoss 5.0.1.GA and JBoss 5.1.0.GA.
> We noticed that the JAAS login in EJB container always picks up the Web app's security domain when the client login is originated from a web application client.  The security domain specified in EJB container's jboss.xml is always ignored in this situation.
> The detailed problem description is posted on JBoss forum:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156863

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 18:53:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 18:53:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1660)
 DuplicateIDCacheImpl won't delete records after reload
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10558691.1245365637754.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic updated JBMESSAGING-1660:
-----------------------------------------

    Fix Version/s: 2.0.0.beta3
                       (was: 2.0.0)


> DuplicateIDCacheImpl won't delete records after reload
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.beta3
>
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 18:53:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 18:53:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1660)
 DuplicateIDCacheImpl won't delete records after reload
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12457649.1245365637343.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic reopened JBMESSAGING-1660:
------------------------------------------



> DuplicateIDCacheImpl won't delete records after reload
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.beta3
>
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 18:55:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 18:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1660)
 DuplicateIDCacheImpl won't delete records after reload
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29613233.1245365756621.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic closed JBMESSAGING-1660.
----------------------------------------

    Resolution: Done


> DuplicateIDCacheImpl won't delete records after reload
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.beta3
>
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 19:33:57 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 18 Jun 2009 19:33:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7033) Upgrade to JBossXACML
	2.0.3.SP2
In-Reply-To: <13425312.1245267716521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4259933.1245368037349.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Stefan Guilhen closed JBAS-7033.
--------------------------------

    Resolution: Done


Trunk and Branch_5_x have been updated to use JBossXACML 2.0.3.SP2.

> Upgrade to JBossXACML 2.0.3.SP2 
> --------------------------------
>
>                 Key: JBAS-7033
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7033
>             Project: JBoss Application Server
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Upgrade to JBossXACML 2.0.3.SP2
> Branch_5_x, trunk and the branch corresponding to EAP5 (find out what branch is that).
> Just update the component/pom.xml
> Run the   ant   tests-security-basic-unit test target and see if there are regressions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 19:35:56 2009
From: jira-events at lists.jboss.org (John Bebbington (JIRA))
Date: Thu, 18 Jun 2009 19:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2129) The
 WorkingMemoryEventListener
 doesn't set the oldObject for objectUpdated method.
Message-ID: <5650920.1245368156655.JavaMail.jira@cloud.prod.atl2.jboss.com>

The WorkingMemoryEventListener doesn't set the oldObject for objectUpdated method.
----------------------------------------------------------------------------------

                 Key: JBRULES-2129
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2129
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.1.0.M1
            Reporter: John Bebbington
            Assignee: Mark Proctor


The org.drools.event.rule.impl.ObjectEventImpl.java class has a fairly obvious error in it's constructor.

The line:
       object = event.getOldObject();
Needs to be changed to:
       oldObject = event.getOldObject();



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 19:43:57 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Thu, 18 Jun 2009 19:43:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11058259.1245368637036.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Richard Kennard commented on JBMETA-208:
----------------------------------------

Alexey,

Apologies, I posted the wrong forum link. It should be...

http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157022

...it is not obvious, at first, that this forum link is about the issue either. That's because this issue causes an unusual side effect (ie. none of your beans get registered with JNDI).

I respect your decision whether to a) fix the code or b) fix the EJB3 docs. However, you might want to at least improve the warning around using EJB3 annotations and (accidentally) an EJB2 deployment descriptor. I only stress this because it used to work in JBoss 4.2.3 (which I know was not fully Java EE 5 compliant, but still).

Richard.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 20:57:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 18 Jun 2009 20:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-56) Add tests that
 bootstraps are shutdown in reverse order from start
In-Reply-To: <30621135.1240858006745.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9099153.1245373076428.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger updated JBBOOT-56:
--------------------------------------

    Attachment: JBBOOT-56.v2.ALR.patch


> Add tests that bootstraps are shutdown in reverse order from start
> ------------------------------------------------------------------
>
>                 Key: JBBOOT-56
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-56
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-base
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: Unscheduled
>
>         Attachments: JBBOOT-56.v1.patch, JBBOOT-56.v2.ALR.patch
>
>
> Ensure that we are shutting down in proper sequence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 20:59:59 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 18 Jun 2009 20:59:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBOOT-56) Add tests that
 bootstraps are shutdown in reverse order from start
In-Reply-To: <30621135.1240858006745.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19680409.1245373199235.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBBOOT-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472899#action_12472899 ] 

Andrew Lee Rubinger commented on JBBOOT-56:
-------------------------------------------

Attached another patch; discussion/explanation on Forum

> Add tests that bootstraps are shutdown in reverse order from start
> ------------------------------------------------------------------
>
>                 Key: JBBOOT-56
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-56
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-base
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: Unscheduled
>
>         Attachments: JBBOOT-56.v1.patch, JBBOOT-56.v2.ALR.patch
>
>
> Ensure that we are shutting down in proper sequence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 20:59:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 18 Jun 2009 20:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-56) Add tests that
 bootstraps are shutdown in reverse order from start
In-Reply-To: <30621135.1240858006745.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28253663.1245373196498.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger updated JBBOOT-56:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238391


> Add tests that bootstraps are shutdown in reverse order from start
> ------------------------------------------------------------------
>
>                 Key: JBBOOT-56
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-56
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-base
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: Unscheduled
>
>         Attachments: JBBOOT-56.v1.patch, JBBOOT-56.v2.ALR.patch
>
>
> Ensure that we are shutting down in proper sequence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 21:52:03 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 21:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1662) Possible
 Performance
 Regression On Small Transactions on AIO if using Linux 2.6.15
Message-ID: <25346013.1245376323276.JavaMail.jira@cloud.prod.atl2.jboss.com>

Possible Performance Regression On Small Transactions on AIO if using Linux 2.6.15
----------------------------------------------------------------------------------

                 Key: JBMESSAGING-1662
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1662
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Clebert Suconic
            Assignee: Tim Fox


Linux 2.6.15 had a bug on nanoSleep. As a result this could hit transactional benchmarks as the minimal buffer timeout would be considered 1 millisecond. 

(This wouldn't bring any problems on scaling up clients)

We are disabling native-timers because of this then.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 21:52:04 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 21:52:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1662) Possible
 Performance
 Regression On Small Transactions on AIO if using Linux 2.6.15
In-Reply-To: <25346013.1245376323276.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9740161.1245376324064.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic updated JBMESSAGING-1662:
-----------------------------------------

        Fix Version/s: 2.0.0.beta3
    Affects Version/s: 2.0.0.beta2


> Possible Performance Regression On Small Transactions on AIO if using Linux 2.6.15
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1662
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1662
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.beta3
>
>
> Linux 2.6.15 had a bug on nanoSleep. As a result this could hit transactional benchmarks as the minimal buffer timeout would be considered 1 millisecond. 
> (This wouldn't bring any problems on scaling up clients)
> We are disabling native-timers because of this then.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 21:52:03 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 21:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1662) Possible
 Performance
 Regression On Small Transactions on AIO if using Linux 2.6.15
In-Reply-To: <25346013.1245376323276.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25732266.1245376323844.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic reassigned JBMESSAGING-1662:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)


> Possible Performance Regression On Small Transactions on AIO if using Linux 2.6.15
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1662
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1662
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.beta3
>
>
> Linux 2.6.15 had a bug on nanoSleep. As a result this could hit transactional benchmarks as the minimal buffer timeout would be considered 1 millisecond. 
> (This wouldn't bring any problems on scaling up clients)
> We are disabling native-timers because of this then.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 21:59:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 21:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1662) Possible
 Performance
 Regression On Small Transactions on AIO if using Linux 2.6.15
In-Reply-To: <25346013.1245376323276.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33408013.1245376796561.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic closed JBMESSAGING-1662.
----------------------------------------

    Resolution: Done


> Possible Performance Regression On Small Transactions on AIO if using Linux 2.6.15
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1662
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1662
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.beta3
>
>
> Linux 2.6.15 had a bug on nanoSleep. As a result this could hit transactional benchmarks as the minimal buffer timeout would be considered 1 millisecond. 
> (This wouldn't bring any problems on scaling up clients)
> We are disabling native-timers because of this then.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 22:28:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 22:28:56 -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: <28303085.1245378536835.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic updated JBMESSAGING-1661:
-----------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> 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://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.4.GA
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 23:18:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Thu, 18 Jun 2009 23:18:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6777) 'interleaving' prop
 on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4146398.1245381537081.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-6777.
---------------------------------

    Resolution: Done


I have this working in deployments that have the local-transaction value false

> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 23:34:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 18 Jun 2009 23:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (SECURITY-420) JBoss Security
 2.0.3.SP2 Release
In-Reply-To: <14028107.1245268807366.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14612004.1245382496865.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana reopened SECURITY-420:
------------------------------------



SECURITY-415 is causing regressions in AS5

> JBoss Security 2.0.3.SP2 Release
> --------------------------------
>
>                 Key: SECURITY-420
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-420
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 23:34:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 18 Jun 2009 23:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (SECURITY-415) ClientLoginModule
 multi-threaded=false should make SecurityContext client side association
In-Reply-To: <12517767.1244524256604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14365380.1245382497004.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana reopened SECURITY-415:
------------------------------------



> ClientLoginModule multi-threaded=false should make SecurityContext client side association
> ------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-415
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-415
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.3.SP1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>
> The ClientLoginModule multi-threaded=false option when missing, should set SecurityContextAssociation.setClient()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 01:13:32 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 19 Jun 2009 01:13:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20651804.1245388412118.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

An EJB-JAR with EJB2 ejb-jar.xml and EJB3 annotations should fail to deploy. I'll have a look.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:03:08 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 19 Jun 2009 03:03:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-995) AUTH:
 FixedMembershipToken is
 based on physical address, won't work with logical addresses
Message-ID: <18811572.1245394988966.JavaMail.jira@cloud.prod.atl2.jboss.com>

AUTH: FixedMembershipToken is based on physical address, won't work with logical addresses
------------------------------------------------------------------------------------------

                 Key: JGRP-995
                 URL: https://jira.jboss.org/jira/browse/JGRP-995
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


The authenticate() method attempts to parse the IP address and port of a message's sender and match it to the fixed_members_value list. However, this won't work as the sender's address is a UUID.

SOLUTION #1: fetch the physical address from TP and compare against the physical address (what if we have multiple physical addresses ?)
SOLUTION #2: additional feature: match against the logical name

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:14:08 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 19 Jun 2009 03:14:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26977679.1245395648354.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Emanuel Muckenhuber commented on JBMETA-208:
--------------------------------------------

There is something like isMetaDataComplete() which is true for ejb2 deployments - so it won't scan for annotations. AFAIK this is also part of the EE spec.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:15:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 19 Jun 2009 03:15:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-996) AUTH: handle multiple
 physical addresses in FixedMembershipToken
Message-ID: <4003443.1245395756979.JavaMail.jira@cloud.prod.atl2.jboss.com>

AUTH: handle multiple physical addresses in FixedMembershipToken
----------------------------------------------------------------

                 Key: JGRP-996
                 URL: https://jira.jboss.org/jira/browse/JGRP-996
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.9




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:39:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 19 Jun 2009 03:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-997) AUTH: incorrect
 matching of src against memberList
Message-ID: <452232.1245397196603.JavaMail.jira@cloud.prod.atl2.jboss.com>

AUTH: incorrect matching of src against memberList
--------------------------------------------------

                 Key: JGRP-997
                 URL: https://jira.jboss.org/jira/browse/JGRP-997
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.6.11




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:48:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 19 Jun 2009 03:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7031) make JMX invoker,
 jmx-console, 
 admin-console, and remote access to Profile Service all use the same
 security domain
In-Reply-To: <112800.1245254636508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5468442.1245397736491.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-7031.
---------------------------------

    Resolution: Done


The profileservice ejbs now use the jmx-console domain and JBossAdmin as the required role

> make JMX invoker, jmx-console, admin-console, and remote access to Profile Service all use the same security domain
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7031
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7031
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This should be done in all configurations - default, all, etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:53:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 19 Jun 2009 03:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-997) AUTH: incorrect
 matching of src against memberList
In-Reply-To: <452232.1245397196603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26753218.1245398036503.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban resolved JGRP-997.
---------------------------

    Resolution: Done


> AUTH: incorrect matching of src against memberList
> --------------------------------------------------
>
>                 Key: JGRP-997
>                 URL: https://jira.jboss.org/jira/browse/JGRP-997
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.6.11
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:53:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 19 Jun 2009 03:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-995) AUTH:
 FixedMembershipToken is
 based on physical address, won't work with logical addresses
In-Reply-To: <18811572.1245394988966.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18004004.1245398036636.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban resolved JGRP-995.
---------------------------

    Resolution: Done


Matching against logical names is left for a later version

> AUTH: FixedMembershipToken is based on physical address, won't work with logical addresses
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-995
>                 URL: https://jira.jboss.org/jira/browse/JGRP-995
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> The authenticate() method attempts to parse the IP address and port of a message's sender and match it to the fixed_members_value list. However, this won't work as the sender's address is a UUID.
> SOLUTION #1: fetch the physical address from TP and compare against the physical address (what if we have multiple physical addresses ?)
> SOLUTION #2: additional feature: match against the logical name

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:56:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 19 Jun 2009 03:56:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-998) AUTH /
 FixedMembershipToken:
 pattern matching and match against logical names
Message-ID: <7649000.1245398217955.JavaMail.jira@cloud.prod.atl2.jboss.com>

AUTH / FixedMembershipToken: pattern matching and match against logical names
-----------------------------------------------------------------------------

                 Key: JGRP-998
                 URL: https://jira.jboss.org/jira/browse/JGRP-998
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.9


#1 Use pattern matching to match hosts against senders, using regular expressions.
#2 Provide matching of logical names in addition to physical addresses

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:56:58 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 19 Jun 2009 03:56:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-998) AUTH /
 FixedMembershipToken:
 pattern matching and match against logical names
In-Reply-To: <7649000.1245398217955.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7165718.1245398218079.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Bela Ban updated JGRP-998:
--------------------------

    Priority: Minor  (was: Major)


> AUTH / FixedMembershipToken: pattern matching and match against logical names
> -----------------------------------------------------------------------------
>
>                 Key: JGRP-998
>                 URL: https://jira.jboss.org/jira/browse/JGRP-998
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.9
>
>
> #1 Use pattern matching to match hosts against senders, using regular expressions.
> #2 Provide matching of logical names in addition to physical addresses

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 06:11:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 19 Jun 2009 06:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1851) Investigate
 the failure
 org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
In-Reply-To: <10648726.1245161216783.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31517224.1245406316744.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472943#action_12472943 ] 

jaikiran pai commented on EJBTHREE-1851:
----------------------------------------

Tried this locally by running this single test. The test passes. But given that this testcase consistenly fails on Hudson jobs and Mike, i guess it has something to do with the testcases that have run before this one. I'll try running a "group" of related testcases to see what it shows.

> Investigate the failure org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
> -------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1851
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1851
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: testsuite
>    Affects Versions: 1.1.7
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> The org.jboss.ejb3.test.container.unit.ContainerTestCase consistently fails with:
> javax.naming.NameNotFoundException: Stateful not bound
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
> 	at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
> 	at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> 	at java.lang.Thread.run(Thread.java:595)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> 	at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at org.jboss.ejb3.test.container.unit.ContainerTestCase.testInvocationStatistics(ContainerTestCase.java:93)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
> 	at junit.extensions.TestSetup.run(TestSetup.java:27)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 07:19:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 19 Jun 2009 07:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21071336.1245410396641.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao updated JBMESSAGING-1657:
------------------------------------

        Fix Version/s: 1.4.0.SP3.CP09
                       1.4.5.GA
    Affects Version/s: 1.4.0.SP3.CP08
                       1.4.0.SP3.CP07


> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05, 1.4.0.SP3.CP07, 1.4.0.SP3.CP08
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 07:28:03 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 19 Jun 2009 07:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11205024.1245410883643.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1657:
-----------------------------------------

The fix:

In GroupMember.multicastConstrol, where ever a multicast message is not received be any member, we do a check on the member's status. If the member is actually dead, it can be safely ignored. the code is like:

   if (!rsp.wasReceived())
   {
      if (!rsp.wasSuspected())
      {
         throw new IllegalStateException(this + " response not received from " + rsp.getSender() + " - there may be others");
      }
   }

where the rsp.wasSuspected() can be used to detected whether the member is really dead or not. (I consulted jgroup lead Bela Ban).



> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05, 1.4.0.SP3.CP07, 1.4.0.SP3.CP08
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 07:33:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 19 Jun 2009 07:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27236793.1245411236580.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao closed JBMESSAGING-1657.
-----------------------------------

    Resolution: Done


> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05, 1.4.0.SP3.CP07, 1.4.0.SP3.CP08
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 07:45:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 19 Jun 2009 07:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28629176.1245411956489.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472962#action_12472962 ] 

jaikiran pai commented on EJBTHREE-1852:
----------------------------------------

We have this working tutorial http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/docs/tutorial/interceptor/META-INF/ejb-jar.xml. Moreover, the line 433 in InterceptorInfoRepository is unlikely to have a NPE. Are you sure, you are not packaging any old versions of jboss jars files within your application? Also, please create a forum thread in the EJB3 user forum so that we can discuss this there http://www.jboss.org/index.html?module=bb&op=viewforum&f=221

> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: deployers, ejb3, interceptors
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 07:51:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 19 Jun 2009 07:51:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13832520.1245412317312.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai updated EJBTHREE-1852:
-----------------------------------

    Component/s: core
                     (was: interceptors)
                     (was: deployers)
                     (was: ejb3)


> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 08:02:06 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 19 Jun 2009 08:02:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1660)
 DuplicateIDCacheImpl won't delete records after reload
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1748233.1245412926878.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox commented on JBMESSAGING-1660:
--------------------------------------

Hey Bijith- It's not related to the issue but I had a couple of comments on your test program:

I noticed you were using ObjectMessage - ObjectMessage in JMS is the slowest message type you can choose (see the perf tuning section in the userguide) since it uses Java serialization. If you're just sending  bytes then you're better off using a BytesMessage or even better, using the core API (not JMS).

Also I noticed you were manually calling acknowledge() on your messages event though the session is auto_acknowledge - in this case the calls to acknowledge() will be ignored. Bear in mind AUTO_ACK is also the slowest ack mode in JMS you can use.

Cheers

> DuplicateIDCacheImpl won't delete records after reload
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.beta3
>
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 08:49:56 2009
From: jira-events at lists.jboss.org (Prem Stephen (JIRA))
Date: Fri, 19 Jun 2009 08:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2130) DSL Bug while
 creating comparison combinations
Message-ID: <17065276.1245415796493.JavaMail.jira@cloud.prod.atl2.jboss.com>

DSL Bug while creating comparison combinations
----------------------------------------------

                 Key: JBRULES-2130
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2130
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.1.FINAL
         Environment: I tried building the DSL using Guvnor

            Reporter: Prem Stephen
            Assignee: Mark Proctor
            Priority: Blocker


In http://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/drools-expert/html_single/index.html#d0e5595, section 4.10.4 - I am expanding on the following syntax example for structuring combinations in the DSL.

In my example, I have

[when]There is a Contact with=Contact()
[when]- age is less than {age}=age < {age}
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}   <-------------------- this line does not work
[when]- age is foo than or equal to {age}=age <= {age}

and my rule is

when
	There is a Contact with
	- age is foo than or equal to 35
	
then
	Log : "Contact exists Test";

Now, the line that does not work is because it shares the start "age is less than " with an earlier DSL.
Replacing "less" with "foo" works for this reason.
I think the parsing needs to be fixed to look at the whole sentence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 08:56:56 2009
From: jira-events at lists.jboss.org (Prem Stephen (JIRA))
Date: Fri, 19 Jun 2009 08:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2131) More flexible
 DSL: sharing of comparison operators between attributes
Message-ID: <14527259.1245416216489.JavaMail.jira@cloud.prod.atl2.jboss.com>

More flexible DSL: sharing of comparison operators between attributes
---------------------------------------------------------------------

                 Key: JBRULES-2131
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2131
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.1.FINAL
         Environment: I tried building the DSL using Guvnor

            Reporter: Prem Stephen
            Assignee: Mark Proctor
            Priority: Blocker


In http://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/drools-expert/html_single/index.html#d0e5595, section 4.10.4 - I am expanding on the following syntax example for structuring combinations in the DSL.

In my example, I have

[when]There is a Contact with=Contact()
[when]- age is less than {age}=age < {age}
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}   <-------------------- this line does not work
[when]- age is foo than or equal to {age}=age <= {age}

and my rule is

when
	There is a Contact with
	- age is foo than or equal to 35
	
then
	Log : "Contact exists Test";

Now, the line that does not work is because it shares the start "age is less than " with an earlier DSL.
Replacing "less" with "foo" works for this reason.
I think the parsing needs to be fixed to look at the whole sentence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 09:03:05 2009
From: jira-events at lists.jboss.org (Prem Stephen (JIRA))
Date: Fri, 19 Jun 2009 09:03:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2131) More flexible
 DSL: sharing of comparison operators between attributes
In-Reply-To: <14527259.1245416216489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31947061.1245416585821.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Prem Stephen updated JBRULES-2131:
----------------------------------

                Issue Type: Feature Request  (was: Bug)
    Workaround Description:   (was: After much experimentation, I found that switching the lines so that "less than or equal to" comes before "less than" does not break.
for eg, this works

[when]There is a Contact with=Contact()
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}
[when]- age is less than {age}=age < {age}

If this cannot be fixed, this quirky behaviour should at the very least be documented.
)
               Environment:     (was: I tried building the DSL using Guvnor
)
               Description: 
In the following DSL
[when]There is a Contact with=Contact()
[when]- age is greater than or equal to {age}=age > {age}
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}
[when]- age is less than {age}=age < {age}

Now, if I had 10 attributes of type int, then currently from what I could read in my documentation I need to recreate these lines for each of these 10 attributes.

Hope about a DSL that is more granular, similar to the one below ( i am just putting this up )
[when][operator]is less than="<"
[when][operator]is less than or equal to ="<="
[when][operator]is greater than=">"
[when][operator]is greater than or equal to =">="

then, I should be able to state that since age is a int, it can use the above operators.
A country, being a String, should not be able to use these operators.

  was:
In http://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/drools-expert/html_single/index.html#d0e5595, section 4.10.4 - I am expanding on the following syntax example for structuring combinations in the DSL.

In my example, I have

[when]There is a Contact with=Contact()
[when]- age is less than {age}=age < {age}
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}   <-------------------- this line does not work
[when]- age is foo than or equal to {age}=age <= {age}

and my rule is

when
	There is a Contact with
	- age is foo than or equal to 35
	
then
	Log : "Contact exists Test";

Now, the line that does not work is because it shares the start "age is less than " with an earlier DSL.
Replacing "less" with "foo" works for this reason.
I think the parsing needs to be fixed to look at the whole sentence.

                  Priority: Critical  (was: Blocker)
                Workaround:   (was: [Workaround Exists])


> More flexible DSL: sharing of comparison operators between attributes
> ---------------------------------------------------------------------
>
>                 Key: JBRULES-2131
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2131
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Prem Stephen
>            Assignee: Mark Proctor
>            Priority: Critical
>
> In the following DSL
> [when]There is a Contact with=Contact()
> [when]- age is greater than or equal to {age}=age > {age}
> [when]- age is greater than {age}=age > {age}
> [when]- age is less than or equal to {age}=age <= {age}
> [when]- age is less than {age}=age < {age}
> Now, if I had 10 attributes of type int, then currently from what I could read in my documentation I need to recreate these lines for each of these 10 attributes.
> Hope about a DSL that is more granular, similar to the one below ( i am just putting this up )
> [when][operator]is less than="<"
> [when][operator]is less than or equal to ="<="
> [when][operator]is greater than=">"
> [when][operator]is greater than or equal to =">="
> then, I should be able to state that since age is a int, it can use the above operators.
> A country, being a String, should not be able to use these operators.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 09:14:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 19 Jun 2009 09:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2131) More flexible DSL:
 sharing of comparison operators between attributes
In-Reply-To: <14527259.1245416216489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19730158.1245417297168.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli closed JBRULES-2131.
----------------------------------

    Fix Version/s: 5.0.1.FINAL
       Resolution: Rejected
         Assignee: Edson Tirelli  (was: Mark Proctor)


This is already possible in the DSL. Just a matter of properly constructing the grammar.

[when][]is less than=<
[when][]- {field:\w*} {operator} {value:\d*}={field} {operator} {value} 

And so on... the order of the entries in the grammar is important.

> More flexible DSL: sharing of comparison operators between attributes
> ---------------------------------------------------------------------
>
>                 Key: JBRULES-2131
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2131
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Prem Stephen
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.0.1.FINAL
>
>
> In the following DSL
> [when]There is a Contact with=Contact()
> [when]- age is greater than or equal to {age}=age > {age}
> [when]- age is greater than {age}=age > {age}
> [when]- age is less than or equal to {age}=age <= {age}
> [when]- age is less than {age}=age < {age}
> Now, if I had 10 attributes of type int, then currently from what I could read in my documentation I need to recreate these lines for each of these 10 attributes.
> Hope about a DSL that is more granular, similar to the one below ( i am just putting this up )
> [when][operator]is less than="<"
> [when][operator]is less than or equal to ="<="
> [when][operator]is greater than=">"
> [when][operator]is greater than or equal to =">="
> then, I should be able to state that since age is a int, it can use the above operators.
> A country, being a String, should not be able to use these operators.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 10:09:56 2009
From: jira-events at lists.jboss.org (John Gilbert (JIRA))
Date: Fri, 19 Jun 2009 10:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14408090.1245420596496.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473003#action_12473003 ] 

John Gilbert commented on EJBTHREE-1852:
----------------------------------------

no, there are no older jar versions.
just took an ear that worked in 4.2.3 and trying to upgrade.
in the debugger bindingXml.interceptorClasses is null

i think the difference between the tutorial and my descriptor is that i am using interceptor-order for the default interceptors.
this was the only way this worked with EJB3StandaloneBootstrap.

> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 10:41:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 10:41:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6989) Fix
 compatibility-matrix tests in Branch_5_x
In-Reply-To: <15176372.1243564628200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2211152.1245422517531.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-6989:
---------------------------------


[waitfor] WARNING: Could not find expected boot lib /TEST/Branch_5_x/tools/lib/trove.jar
  [waitfor] Failed to boot JBoss:
  [waitfor] java.lang.IllegalArgumentException: Specified implementation class could not be found: org.jboss.bootstrap.impl.as.server.JBossASServerImpl on ClassLoader java.net.URLClassLoader at 7a5a19
  [waitfor]     at org.jboss.bootstrap.spi.factory.GenericFactory.createInstance(GenericFactory.java:92)
  [waitfor]     at org.jboss.bootstrap.spi.factory.ServerFactory.createServer(ServerFactory.java:83)
  [waitfor]     at org.jboss.Main.boot(Main.java:364)
  [waitfor]     at org.jboss.Main$1.run(Main.java:727)
  [waitfor]     at java.lang.Thread.run(Thread.java:595)
  [waitfor] Caused by: java.lang.ClassNotFoundException: org.jboss.bootstrap.impl.as.server.JBossASServerImpl
  [waitfor]     at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
  [waitfor]     at java.security.AccessController.doPrivileged(Native Method)
  [waitfor]     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
  [waitfor]     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
  [waitfor]     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
  [waitfor]     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
  [waitfor]     at java.lang.Class.forName0(Native Method)
  [waitfor]     at java.lang.Class.forName(Class.java:242)
  [waitfor]     at org.jboss.bootstrap.spi.factory.GenericFactory.createInstance(GenericFactory.java:88)


> Fix compatibility-matrix tests in Branch_5_x
> --------------------------------------------
>
>                 Key: JBAS-6989
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6989
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Need to sync with new bootstrap implementation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 10:45:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 10:45:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6968)
 org.jboss.test.spring.test.SpringClusterTestCase failing with IBM JDK 1.5
In-Reply-To: <32698421.1243001398195.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28474768.1245422757628.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-6968:
---------------------------------


The fix has been commited to the JBPAPP_5_0 branch, rev 90367.   Need to commit to Branch_5_x and trunk.

> org.jboss.test.spring.test.SpringClusterTestCase failing with IBM JDK 1.5
> -------------------------------------------------------------------------
>
>                 Key: JBAS-6968
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6968
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: spring-server.log
>
>
> org.jboss.test.spring.test.SpringClusterTestCase is failing with this message:
> testStandalone	Failure	N/A
> junit.framework.AssertionFailedError
> 	at org.jboss.test.spring.test.SpringClusterTestCase.testStandalone(SpringClusterTestCase.java:43)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> In the server log you can see:
> ...
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/lib/spring-cluster-pojos.jar/" is in error due to the following reason(s): java.lang.ClassNotFoundException: net.jcip.annotations.ThreadSafe
> ...
> Which shows that it is again the same problem with net.jcip.annotations.ThreadSafe missing in IBM JDK as discussed here JBAS-6934 and JBAS-6428.
> Solution: Ensure that jcip-annotations.jar gets copied to server/springdeployer/lib/ when the config is created.
> A. Add jcip-annotations.jar to server/default/lib (it is 2.6 KB) - springdeployer is created out of default
> B. Change testsuite/build.xml to make ant copy jcip-annotations.jar from server/all/lib/ to server/springdeployer/lib/ - don't know how to do that easily
> A. seems easier to do.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 10:45:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 10:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6967)
 org.jboss.test.security.test.HttpsUnitTestCase failing with IBM JDK
In-Reply-To: <27953188.1242999477645.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23692014.1245422756791.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-6967:
---------------------------------


This has been fixed in the JBPAPP_5_0 branch, rev 90367.  Need to commit to Branch_5_x and trunk.

> org.jboss.test.security.test.HttpsUnitTestCase failing with IBM JDK
> -------------------------------------------------------------------
>
>                 Key: JBAS-6967
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6967
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: TEST-org.jboss.test.security.test.HttpsUnitTestCase-tests-security-basic-unit.xml
>
>
> When running the AS testsuite, this test case shows an error:
> org.jboss.test.security.test.HttpsUnitTestCase
> The error message is:
> unknown	Error	N/A
> java.lang.NullPointerException
> 	at java.security.Security.insertProviderAt(Security.java:357)
> 	at java.security.Security.addProvider(Security.java:406)
> 	at org.jboss.test.security.test.HttpsUnitTestCase$1.setUp(HttpsUnitTestCase.java:171)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> When you look in the source code, this is the line where it fails:
> Security.addProvider(SecurityProviderUtil.getJSSEProvider());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 10:47:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 10:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6962)
 org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
In-Reply-To: <994948.1242838745393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25508177.1245422876614.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-6962:
---------------------------------


The fix has been commited to the JBPAPP_5_0 branch, rev 90367.   Need to commit to Branch_5_x and trunk.


> org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
> ----------------------------------------------------------------------
>
>                 Key: JBAS-6962
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6962
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: TEST-org.jboss.test.cmp2.commerce.CompleteUnitTestCase.xml
>
>
> With IBM JDK 1.6 the test testJBossQL fails with this message:
> Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> junit.framework.AssertionFailedError: Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> 	at org.jboss.test.cmp2.commerce.QueryTest.testJBossQL(QueryTest.java:169)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)
> It's strange that with IBM 1.6 the failure does not happen in that test, but in different - testEJBQL:
> expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> junit.framework.ComparisonFailure: expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> 	at org.jboss.test.cmp2.commerce.QueryTest.testEJBQL(QueryTest.java:329)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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:193)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Fri Jun 19 10:49:56 2009
From: jira-events at lists.jboss.org (Prem Stephen (JIRA))
Date: Fri, 19 Jun 2009 10:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2132) Patch: Docs:
 Expert: Rule Language chapter: DSL Section
Message-ID: <19253271.1245422996891.JavaMail.jira@cloud.prod.atl2.jboss.com>

Patch: Docs: Expert: Rule Language chapter: DSL Section
-------------------------------------------------------

                 Key: JBRULES-2132
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2132
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.1.FINAL
            Reporter: Prem Stephen
            Assignee: Edson Tirelli
            Priority: Critical
             Fix For: 5.0.1.FINAL


In the following DSL
[when]There is a Contact with=Contact()
[when]- age is greater than or equal to {age}=age > {age}
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}
[when]- age is less than {age}=age < {age}

Now, if I had 10 attributes of type int, then currently from what I could read in my documentation I need to recreate these lines for each of these 10 attributes.

Hope about a DSL that is more granular, similar to the one below ( i am just putting this up )
[when][operator]is less than="<"
[when][operator]is less than or equal to ="<="
[when][operator]is greater than=">"
[when][operator]is greater than or equal to =">="

then, I should be able to state that since age is a int, it can use the above operators.
A country, being a String, should not be able to use these operators.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 10:51:56 2009
From: jira-events at lists.jboss.org (Prem Stephen (JIRA))
Date: Fri, 19 Jun 2009 10:51:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2132) Patch: Docs:
 Expert: Rule Language chapter: DSL Section
In-Reply-To: <19253271.1245422996891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4329811.1245423116861.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Prem Stephen updated JBRULES-2132:
----------------------------------

     Issue Type: Support Patch  (was: Feature Request)
    Description: 
I have added additional documentation for DSL and am submitting 2 files.
The one marked "new" has my changes.
The one I used to modify is also attached, for diff, if needed

  was:
In the following DSL
[when]There is a Contact with=Contact()
[when]- age is greater than or equal to {age}=age > {age}
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}
[when]- age is less than {age}=age < {age}

Now, if I had 10 attributes of type int, then currently from what I could read in my documentation I need to recreate these lines for each of these 10 attributes.

Hope about a DSL that is more granular, similar to the one below ( i am just putting this up )
[when][operator]is less than="<"
[when][operator]is less than or equal to ="<="
[when][operator]is greater than=">"
[when][operator]is greater than or equal to =">="

then, I should be able to state that since age is a int, it can use the above operators.
A country, being a String, should not be able to use these operators.

        Affects: [Documentation (Ref Guide, User Guide, etc.)]


> Patch: Docs: Expert: Rule Language chapter: DSL Section
> -------------------------------------------------------
>
>                 Key: JBRULES-2132
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2132
>             Project: JBoss Drools
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Prem Stephen
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.0.1.FINAL
>
>
> I have added additional documentation for DSL and am submitting 2 files.
> The one marked "new" has my changes.
> The one I used to modify is also attached, for diff, if needed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 10:53:56 2009
From: jira-events at lists.jboss.org (Prem Stephen (JIRA))
Date: Fri, 19 Jun 2009 10:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2132) Patch: Docs:
 Expert: Rule Language chapter: DSL Section
In-Reply-To: <19253271.1245422996891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33337765.1245423236768.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Prem Stephen updated JBRULES-2132:
----------------------------------

    Attachment: Section-DSL.xml
                Section-DSL-new.xml


> Patch: Docs: Expert: Rule Language chapter: DSL Section
> -------------------------------------------------------
>
>                 Key: JBRULES-2132
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2132
>             Project: JBoss Drools
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Prem Stephen
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.0.1.FINAL
>
>         Attachments: Section-DSL-new.xml, Section-DSL.xml
>
>
> I have added additional documentation for DSL and am submitting 2 files.
> The one marked "new" has my changes.
> The one I used to modify is also attached, for diff, if needed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 11:09:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 19 Jun 2009 11:09:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMETA-209) jboss-metadata
 trunk test compilation fails in JDK5
In-Reply-To: <9131641.1245260636508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21125558.1245424197106.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger reopened JBMETA-209:
----------------------------------------



Reopening until merged into the new split metadata

> jboss-metadata trunk test compilation fails in JDK5
> ---------------------------------------------------
>
>                 Key: JBMETA-209
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-209
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.0.2.Beta2
>
>
> [INFO] Compilation failure
> /home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
> symbol  : method stringPropertyNames()
> location: class java.util.Properties
> /home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
> symbol  : method stringPropertyNames()
> location: class java.util.Properties

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 11:47:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 11:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6989) Fix
 compatibility-matrix tests in Branch_5_x
In-Reply-To: <15176372.1243564628200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8096317.1245426476522.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan resolved JBAS-6989.
----------------------------------

    Resolution: Done


added  java.endorsed.dirs to start-jboss

> Fix compatibility-matrix tests in Branch_5_x
> --------------------------------------------
>
>                 Key: JBAS-6989
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6989
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Need to sync with new bootstrap implementation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 12:59:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 19 Jun 2009 12:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-531) Build classpaths
 directly against jars in local maven repository
In-Reply-To: <6026725.1243637396349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6147270.1245430796717.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Paul Gier reassigned JBBUILD-531:
---------------------------------

    Assignee: Paul Gier


> Build classpaths directly against jars in local maven repository
> ----------------------------------------------------------------
>
>                 Key: JBBUILD-531
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-531
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the testsuite uses the jars in thirdparty.  Instead the paths in the testsuite should directly reference jars in the local maven repository directory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 13:04:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 19 Jun 2009 13:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-419) Enable testsuite
 to run against maven generated artifacts.
In-Reply-To: <20791453.1189779191245.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26254461.1245431096414.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Paul Gier updated JBBUILD-419:
------------------------------

        Parent: JBBUILD-529
    Issue Type: Sub-task  (was: Task)


> Enable testsuite to run against maven generated artifacts.
> ----------------------------------------------------------
>
>                 Key: JBBUILD-419
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-419
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Once maven is able to generate matching artifacts for the ant build, the testsuite will have to be run against the maven generated stuff.  This will probably involve some modifications to the testsuite.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 14:45:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 14:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6966) Some tests fail
 with IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
In-Reply-To: <28786754.1242998527053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21389103.1245437156794.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan commented on JBAS-6966:
--------------------------------------

IBM JDK 5 nor 6 supports specifying SSLv2Hello:
http://www.ibm.com/developerworks/java/jdk/security/60/secguides/jsse2Docs/JSSE2RefGuide.html#knowndiffsun
http://www.ibm.com/developerworks/java/jdk/security/50/secguides/jsse2Docs/JSSE2RefGuide.html#knowndiffsun
Specifically,
IBM implementation supports the following protocols: SSL, SSLv3, TLS, TLSv1, and SSL_TLS for engine class SSLContext or the API setEnabledProtocols in the SSLSocket or SSLServerSocket classes. It does not support specifying SSLv2Hello. A server side connection always accepts an SSLv2Hello. The IBM SSLContext getInstance factory method can be used to control which protocols actually get enabled for an SSL connection. Using the SSLContext getInstance or the setEnabledProtocols method give the same result. The Sun JSSE controls which protocols are actually enabled for an SSL connection through setEnabledProtocols.

> Some tests fail with IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
> -----------------------------------------------------------------------------
>
>                 Key: JBAS-6966
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6966
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: SSLv2Hello-error
>
>
> Some tests in the testsuite are failing due to IBM JDK not supporting the SSLv2Hello protocol:
> 15:10:46,727 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=invoker,socketType=SSLSocketFactory,type=jrmp,wantsClientAuth=true state=Create mode=Manual requiredState=Installed
> java.lang.IllegalArgumentException: SSLv2Hello
> 	at com.ibm.jsse2.mb.a(mb.java:24)
> 	at com.ibm.jsse2.lb.<init>(lb.java:41)
> 	at com.ibm.jsse2.hc.setEnabledProtocols(hc.java:57)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:267)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:226)
> 	at org.jboss.security.ssl.RMISSLServerSocketFactory.createServerSocket(RMISSLServerSocketFactory.java:120)
> 	at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:638)
> 	at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:272)
> 	at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:219)
> 	at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:398)
> ...
> This problem was previously reported as JBPAPP-626 but never fixed. I'm creating a new JIRA since it now affects more testcases.
> These testcases fail:
> org.jboss.test.jrmp.test.CustomSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLFailuresSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLSocketsUnitTestCase
> org.jboss.test.pooled.test.SSLSocketsUnitTestCase
> We can still leave it as it is - meaning documenting these failures as known issues with IBM JDK. I just wanted to make sure we know about it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 15:10:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 15:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6966) Some tests fail with
 IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
In-Reply-To: <28786754.1242998527053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3574770.1245438656961.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-6966:
---------------------------------

    Affects: [Documentation (Ref Guide, User Guide, etc.), Release Notes]


> Some tests fail with IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
> -----------------------------------------------------------------------------
>
>                 Key: JBAS-6966
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6966
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: SSLv2Hello-error
>
>
> Some tests in the testsuite are failing due to IBM JDK not supporting the SSLv2Hello protocol:
> 15:10:46,727 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=invoker,socketType=SSLSocketFactory,type=jrmp,wantsClientAuth=true state=Create mode=Manual requiredState=Installed
> java.lang.IllegalArgumentException: SSLv2Hello
> 	at com.ibm.jsse2.mb.a(mb.java:24)
> 	at com.ibm.jsse2.lb.<init>(lb.java:41)
> 	at com.ibm.jsse2.hc.setEnabledProtocols(hc.java:57)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:267)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:226)
> 	at org.jboss.security.ssl.RMISSLServerSocketFactory.createServerSocket(RMISSLServerSocketFactory.java:120)
> 	at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:638)
> 	at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:272)
> 	at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:219)
> 	at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:398)
> ...
> This problem was previously reported as JBPAPP-626 but never fixed. I'm creating a new JIRA since it now affects more testcases.
> These testcases fail:
> org.jboss.test.jrmp.test.CustomSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLFailuresSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLSocketsUnitTestCase
> org.jboss.test.pooled.test.SSLSocketsUnitTestCase
> We can still leave it as it is - meaning documenting these failures as known issues with IBM JDK. I just wanted to make sure we know about it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 15:12:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 19 Jun 2009 15:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6966) Some tests fail
 with IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
In-Reply-To: <28786754.1242998527053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5370508.1245438776603.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Anil Saldhana commented on JBAS-6966:
-------------------------------------

Lets deprecate SSLv2

> Some tests fail with IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
> -----------------------------------------------------------------------------
>
>                 Key: JBAS-6966
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6966
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: SSLv2Hello-error
>
>
> Some tests in the testsuite are failing due to IBM JDK not supporting the SSLv2Hello protocol:
> 15:10:46,727 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=invoker,socketType=SSLSocketFactory,type=jrmp,wantsClientAuth=true state=Create mode=Manual requiredState=Installed
> java.lang.IllegalArgumentException: SSLv2Hello
> 	at com.ibm.jsse2.mb.a(mb.java:24)
> 	at com.ibm.jsse2.lb.<init>(lb.java:41)
> 	at com.ibm.jsse2.hc.setEnabledProtocols(hc.java:57)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:267)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:226)
> 	at org.jboss.security.ssl.RMISSLServerSocketFactory.createServerSocket(RMISSLServerSocketFactory.java:120)
> 	at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:638)
> 	at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:272)
> 	at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:219)
> 	at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:398)
> ...
> This problem was previously reported as JBPAPP-626 but never fixed. I'm creating a new JIRA since it now affects more testcases.
> These testcases fail:
> org.jboss.test.jrmp.test.CustomSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLFailuresSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLSocketsUnitTestCase
> org.jboss.test.pooled.test.SSLSocketsUnitTestCase
> We can still leave it as it is - meaning documenting these failures as known issues with IBM JDK. I just wanted to make sure we know about it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 16:04:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 16:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6934) Tests in
 org.jboss.test.cluster failing with IBM JDK 1.5 - Failed to start
 cluster/http/jboss-web-test-service.xml
In-Reply-To: <23484241.1242648377491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13732568.1245441896867.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-6934:
---------------------------------


Added <path refid="net.jcip.classpath"/> to library.classpath in JBPAPP_5_0 branch, rev 90479.  Will resolve once committed to trunk.

> Tests in org.jboss.test.cluster failing with IBM JDK 1.5 - Failed to start cluster/http/jboss-web-test-service.xml
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6934
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6934
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>
> Some clustered tests are failing with this error message:
> Failed to start cluster/http/jboss-web-test-service.xml
> org.jboss.cache.pojo.PojoCacheException: Failed to start cluster/http/jboss-web-test-service.xml
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.<init>(PojoCacheImpl.java:63)
> 	at org.jboss.cache.pojo.PojoCacheFactory.createCache(PojoCacheFactory.java:42)
> 	at org.jboss.test.cluster.testutil.SessionTestUtil.getConfiguration(SessionTestUtil.java:147)
> 	at org.jboss.test.cluster.testutil.SessionTestUtil.createCache(SessionTestUtil.java:136)
> 	at org.jboss.test.cluster.testutil.CacheConfigTestSetup.setUp(CacheConfigTestSetup.java:84)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: org.jboss.cache.config.ConfigurationException: Unable to build interceptor chain
> 	at org.jboss.cache.factories.InterceptorChainFactory.construct(InterceptorChainFactory.java:229)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:318)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.DefaultCacheFactory.bootstrap(DefaultCacheFactory.java:155)
> 	at org.jboss.cache.DefaultCacheFactory.createAndWire(DefaultCacheFactory.java:141)
> 	at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:120)
> 	at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:93)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.<init>(PojoCacheImpl.java:58)
> Caused by: java.lang.TypeNotPresentException: Type net.jcip.annotations.ThreadSafe not present
> 	at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:38)
> 	at com.ibm.oti.reflect.AnnotationHelper.getDeclaredAnnotations(AnnotationHelper.java:50)
> 	at java.lang.Class.getDeclaredAnnotations(Class.java:1620)
> 	at java.lang.Class.getAnnotations(Class.java:1581)
> 	at java.lang.Class.getAnnotation(Class.java:1561)
> 	at java.lang.Class.isAnnotationPresent(Class.java:1648)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:252)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.InterceptorChainFactory.createInterceptor(InterceptorChainFactory.java:60)
> 	at org.jboss.cache.factories.InterceptorChainFactory.buildInterceptorChain(InterceptorChainFactory.java:75)
> 	at org.jboss.cache.factories.InterceptorChainFactory.construct(InterceptorChainFactory.java:225)
> Caused by: java.lang.ClassNotFoundException: net.jcip.annotations.ThreadSafe
> 	at java.lang.Class.forName(Class.java:163)
> 	at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:33)
> This is the list of the tests failing because of this: 
> org.jboss.test.cluster.defaultcfg.simpleweb.test.AttributeBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.BuddyReplicationFailoverUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.BuddyReplicationToPassivatedSessionUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.ClusteredSessionNotificationPolicyTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.FieldBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.JBossCacheManagerConfigurationUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.ReplicationToPassivatedSessionUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionCountUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionExpirationUnitTestCase
> In total it causes 29 failures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 16:19:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 19 Jun 2009 16:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21636392.1245442796624.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473088#action_12473088 ] 

Andrew Lee Rubinger commented on EJBTHREE-995:
----------------------------------------------

Discussed w/ Gavin; we'll write up an integration test which includes AS, then close out if still not present.  Then notify Seam team to remove workaround hacks in https://anonsvn.jboss.org/repos/seam/trunk/src/main/java/org/jboss/seam/transaction/EjbSynchronizations.java

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 18:10:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 19 Jun 2009 18:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-6777) 'interleaving' prop
 on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16241488.1245449456687.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer reopened JBAS-6777:
--------------------------------



Using EAP branch r90482, the 'interleaving' prop still gets reset to false by the Profile Service after I set it to true via a component update. I tried with both an XA Datasource and a Tx Connection Factory with XA enabled. Did you forget to check the fix into the EAP branch?


> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 18:32:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 19 Jun 2009 18:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6777) 'interleaving'
 prop on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6156479.1245450776783.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark commented on JBAS-6777:
-------------------------------------

Yes, its in the https://svn.jboss.org/repos/jbossas/branches/JBPAPP_5_0 and the test is validating that the interleaving property is true on the underlying component:

      // Query the interleaving 
      ManagementView mgtView = getManagementView();
      ComponentType type = KnownComponentTypes.DataSourceTypes.XA.getType();
      ManagedComponent txcf = mgtView.getComponent(jndiName, type);
      assertNotNull(txcf);
      ManagedProperty interleaving = txcf.getProperty("interleaving");
      assertNotNull("interleaving", interleaving);
      MetaValue interleavingMV = interleaving.getValue();
      assertNotNull("interleaving.value", interleavingMV);
      assertEquals("interleaving.value is true", SimpleValueSupport.wrap(Boolean.TRUE), interleavingMV);

Can you attach the ds.xml file that is showing the false value.


> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 18:49:08 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 19 Jun 2009 18:49:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6777) 'interleaving'
 prop on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14485549.1245451748079.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer commented on JBAS-6777:
------------------------------------

For an existing ds.xml that contains the <interleaving/> tag, the interleaving managed prop is true; so that part of it appears to be fixed. The issue that still exists is that when I call updatecomponent() on the management view and then load() on the management view, the managed prop's value has been reset to false. Similarly, when I have an existing datasource or conn factory with interleaving set to false, when I try to change it to true via the PS and then reload the view, its value is still false.

> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 19:22:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 19 Jun 2009 19:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6777) 'interleaving'
 prop on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14124040.1245453776612.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark commented on JBAS-6777:
-------------------------------------

Ok, I'll create a test that attempts to change the value from false to true.


> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 00:02:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 00:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6720) Make sure that the
 metrics for
 Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as
 ViewUse.STATISTIC
In-Reply-To: <7508166.1238615242987.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18971227.1245470577000.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene commented on JBAS-6720:
---------------------------------------

Farah, I looked into the questions you asked (finally)

Count Delta
-------------------
This metric returns the difference in count since the last read of Count Delta. So if you call it twice quickly, and there are no messages sent between the calls, you get 0.

Time Last Update
-----------------------
This value represents the last time statistics where calculated by the messaging system. It is fired off of a timer, so the message count can be zero and it will still update

> Make sure that the metrics for Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as ViewUse.STATISTIC
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6720
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6720
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: JBoss AS Branch_5_x r86586, embjopr r266
> EmbJopr TS: testQueueMetrics
>            Reporter: Farah Juma
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Steps to reproduce:
> Create a new Topic or Queue using Embedded Jopr. Send some messages to the Topic or Queue. Navigate to the "Metrics" tab for the resource. The metrics do not get updated to reflect this change. All the values are 0.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:09:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7038) Track component
 update - 5.2.0.Beta1
In-Reply-To: <2791010.1245334316593.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30668441.1245474596428.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene reassigned JBAS-7038:
-------------------------------------

    Assignee: Jason T. Greene


> Track component update - 5.2.0.Beta1
> ------------------------------------
>
>                 Key: JBAS-7038
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7038
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Jason T. Greene
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:11:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7040) Update MDR to
	2.0.2.GA
In-Reply-To: <15426592.1245474716667.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14745418.1245474716825.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene updated JBAS-7040:
----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> Update MDR to 2.0.2.GA
> ----------------------
>
>                 Key: JBAS-7040
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7040
>             Project: JBoss Application Server
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: MicroContainer bus
>            Reporter: Jason T. Greene
>            Assignee: Ales Justin
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:11:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7040) Update MDR to
	2.0.2.GA
Message-ID: <15426592.1245474716667.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update MDR to 2.0.2.GA
----------------------

                 Key: JBAS-7040
                 URL: https://jira.jboss.org/jira/browse/JBAS-7040
             Project: JBoss Application Server
          Issue Type: Component Upgrade
      Security Level: Public (Everyone can see)
          Components: MicroContainer bus
            Reporter: Jason T. Greene
            Assignee: Ales Justin




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:11:57 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:11:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7042) Update Deployers to
	2.0.8.GA
Message-ID: <3578800.1245474717340.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update Deployers to 2.0.8.GA
----------------------------

                 Key: JBAS-7042
                 URL: https://jira.jboss.org/jira/browse/JBAS-7042
             Project: JBoss Application Server
          Issue Type: Component Upgrade
      Security Level: Public (Everyone can see)
          Components: MicroContainer bus
            Reporter: Jason T. Greene
            Assignee: Ales Justin
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:11:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7040) Update MDR to 2.0.2.GA
In-Reply-To: <15426592.1245474716667.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6629930.1245474717000.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene closed JBAS-7040.
---------------------------------

    Resolution: Done


> Update MDR to 2.0.2.GA
> ----------------------
>
>                 Key: JBAS-7040
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7040
>             Project: JBoss Application Server
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: MicroContainer bus
>            Reporter: Jason T. Greene
>            Assignee: Ales Justin
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:14:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7042) Update Deployers to
	2.0.8.GA
In-Reply-To: <3578800.1245474717340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19341480.1245474896767.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene closed JBAS-7042.
---------------------------------

    Resolution: Done


> Update Deployers to 2.0.8.GA
> ----------------------------
>
>                 Key: JBAS-7042
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7042
>             Project: JBoss Application Server
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: MicroContainer bus
>            Reporter: Jason T. Greene
>            Assignee: Ales Justin
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:14:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7041) Update Kernel to
	2.0.7.GA
In-Reply-To: <31182505.1245474717156.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30861784.1245474896594.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene closed JBAS-7041.
---------------------------------

    Resolution: Done


> Update Kernel to 2.0.7.GA
> -------------------------
>
>                 Key: JBAS-7041
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7041
>             Project: JBoss Application Server
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: MicroContainer bus
>            Reporter: Jason T. Greene
>            Assignee: Ales Justin
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:11:57 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:11:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7041) Update Kernel to
	2.0.7.GA
Message-ID: <31182505.1245474717156.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update Kernel to 2.0.7.GA
-------------------------

                 Key: JBAS-7041
                 URL: https://jira.jboss.org/jira/browse/JBAS-7041
             Project: JBoss Application Server
          Issue Type: Component Upgrade
      Security Level: Public (Everyone can see)
          Components: MicroContainer bus
            Reporter: Jason T. Greene
            Assignee: Ales Justin
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:59:08 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:59:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS Topics
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16213372.1245477548631.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene updated JBAS-6783:
----------------------------------

        Summary: NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics  (was: NPE when setting 'messageCounterHistoryDayLimit' prop on JMS destinations)
    Component/s: JMS (JBoss Messaging)
                     (was: ProfileService)
    Description: 
Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:

Caused by: java.lang.NullPointerException
	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)

Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .

The problem is that the property is only expected to be set at runtime, AFTER the topic has started:

 Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);




  was:
Reporting this on behalf of Emanuel.


See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 for his original comments.
In todays meeting he mentioned you get an NPE when setting the messageCounterHistoryDayLimit  property.


More investigation is needed.



> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics
> -------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:
> Caused by: java.lang.NullPointerException
> 	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
> 	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)
> Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .
> The problem is that the property is only expected to be set at runtime, AFTER the topic has started:
>  Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:59:08 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:59:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS Topics
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25004208.1245477548954.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene reassigned JBAS-6783:
-------------------------------------

    Assignee: Howard Gao  (was: Jason T. Greene)


> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics
> -------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Howard Gao
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:
> Caused by: java.lang.NullPointerException
> 	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
> 	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)
> Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .
> The problem is that the property is only expected to be set at runtime, AFTER the topic has started:
>  Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 02:00:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 02:00:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS Topics
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16346419.1245477656602.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene updated JBAS-6783:
----------------------------------

    Description: 
Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:

<attribute name="MessageCounterHistoryDayLimit">10</attribute>

Caused by: java.lang.NullPointerException
	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)

Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .

The problem is that the property is only expected to be set at runtime, AFTER the topic has started:

 Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);




  was:
Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:

Caused by: java.lang.NullPointerException
	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)

Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .

The problem is that the property is only expected to be set at runtime, AFTER the topic has started:

 Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);






> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics
> -------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Howard Gao
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:
> <attribute name="MessageCounterHistoryDayLimit">10</attribute>
> Caused by: java.lang.NullPointerException
> 	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
> 	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)
> Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .
> The problem is that the property is only expected to be set at runtime, AFTER the topic has started:
>  Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 02:02:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 02:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS Topics
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9319609.1245477776576.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jason T. Greene commented on JBAS-6783:
---------------------------------------

The fix should be to change the setMessageCounterHistoryDayLimit to not update the counters if they don't exist yet (serverPeer doesn't exist yet)

> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics
> -------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Howard Gao
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:
> <attribute name="MessageCounterHistoryDayLimit">10</attribute>
> Caused by: java.lang.NullPointerException
> 	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
> 	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)
> Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .
> The problem is that the property is only expected to be set at runtime, AFTER the topic has started:
>  Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 12:48:18 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Sat, 20 Jun 2009 12:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1663) Release JBoss
 Messaging 2.0.0.Beta3
Message-ID: <27353572.1245516498941.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release JBoss Messaging 2.0.0.Beta3
-----------------------------------

                 Key: JBMESSAGING-1663
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1663
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Clebert Suconic
            Assignee: Clebert Suconic




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 17:11:04 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Sat, 20 Jun 2009 17:11:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1663) Release JBoss
 Messaging 2.0.0.Beta3
In-Reply-To: <27353572.1245516498941.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10772870.1245532266035.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic updated JBMESSAGING-1663:
-----------------------------------------

    Attachment: messaging-2.0.0.BETA3-noDocs.zip


> Release JBoss Messaging 2.0.0.Beta3
> -----------------------------------
>
>                 Key: JBMESSAGING-1663
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1663
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>         Attachments: messaging-2.0.0.BETA3-noDocs.zip
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 22:42:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Sat, 20 Jun 2009 22:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1663) Release JBoss
 Messaging 2.0.0.Beta3
In-Reply-To: <27353572.1245516498941.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11979459.1245552176755.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic updated JBMESSAGING-1663:
-----------------------------------------

    Attachment:     (was: messaging-2.0.0.BETA3-noDocs.zip)


> Release JBoss Messaging 2.0.0.Beta3
> -----------------------------------
>
>                 Key: JBMESSAGING-1663
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1663
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 22:44:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Sat, 20 Jun 2009 22:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1663) Release JBoss
 Messaging 2.0.0.Beta3
In-Reply-To: <27353572.1245516498941.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15619414.1245552296797.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic updated JBMESSAGING-1663:
-----------------------------------------

    Attachment: messaging-2


> Release JBoss Messaging 2.0.0.Beta3
> -----------------------------------
>
>                 Key: JBMESSAGING-1663
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1663
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>         Attachments: messaging-1, messaging-2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 22:44:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Sat, 20 Jun 2009 22:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1663) Release JBoss
 Messaging 2.0.0.Beta3
In-Reply-To: <27353572.1245516498941.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32104892.1245552296539.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic updated JBMESSAGING-1663:
-----------------------------------------

    Attachment: messaging-1


> Release JBoss Messaging 2.0.0.Beta3
> -----------------------------------
>
>                 Key: JBMESSAGING-1663
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1663
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>         Attachments: messaging-1, messaging-2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 13:52:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Sun, 21 Jun 2009 13:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7043) /docs/schema does
 not contain bean-deployer xsds
Message-ID: <2403334.1245606776409.JavaMail.jira@cloud.prod.atl2.jboss.com>

/docs/schema does not contain bean-deployer xsds
------------------------------------------------

                 Key: JBAS-7043
                 URL: https://jira.jboss.org/jira/browse/JBAS-7043
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Wolfgang Knauf


The microcontainer related schema definitions can currently be found only in "lib\jboss-kernel.jar", but they should also be placed in "docs\schema" in the JBoss installation like all the other schema definitions.

The files are:
-bean-deployer_1_0.xsd
-bean-deployer_2_0.xsd
-jboss-beans-common_2_0.xsd
-policy_1_0.xsd

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 13:27:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Sun, 21 Jun 2009 13:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMICROCONT-446) bean-deployer
 xsds don't contain web references
Message-ID: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>

bean-deployer xsds don't contain web references
-----------------------------------------------

                 Key: JBMICROCONT-446
                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
             Project: JBoss Microcontainer
          Issue Type: Bug
            Reporter: Wolfgang Knauf


bean-deployer_2_0.xsd:

   <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">

=>should point. 
   <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">

The comment for a sample instance should also contain a schema location attribute:
         <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns="urn:jboss:bean-deployer:2.0"
            xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">

==================
bean-deployer_1_0.xsd:

The comment for a sample instance should point to the web schema location:
         <deployment
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
            xmlns="urn:jboss:bean-deployer">

=================
policy_1_0.xsd:
   <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
should be:
   <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>

=================
bean-deployer_2_0.xsd raises validation errors in Eclipse:
-rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
-src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 13:29:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Sun, 21 Jun 2009 13:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMICROCONT-446) bean-deployer
 xsds don't contain web references
In-Reply-To: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9752426.1245605396430.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Wolfgang Knauf updated JBMICROCONT-446:
---------------------------------------

    Description: 
bean-deployer_2_0.xsd:

   <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">

=>should point. 
   <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">

The comment for a sample instance should also contain a schema location attribute:
         <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns="urn:jboss:bean-deployer:2.0"
            xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">

==================
bean-deployer_1_0.xsd:

The comment for a sample instance should point to the web schema location:
         <deployment
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
            xmlns="urn:jboss:bean-deployer">

=================
policy_1_0.xsd:
   <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
should be:
   <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>

=================
bean-deployer_2_0.xsd raises validation errors in Eclipse:
-rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
-src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

  was:
bean-deployer_2_0.xsd:

   <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">

=>should point. 
   <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">

The comment for a sample instance should also contain a schema location attribute:
         <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns="urn:jboss:bean-deployer:2.0"
            xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">

==================
bean-deployer_1_0.xsd:

The comment for a sample instance should point to the web schema location:
         <deployment
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
            xmlns="urn:jboss:bean-deployer">

=================
policy_1_0.xsd:
   <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
should be:
   <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>

=================
bean-deployer_2_0.xsd raises validation errors in Eclipse:
-rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
-src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.



> bean-deployer xsds don't contain web references
> -----------------------------------------------
>
>                 Key: JBMICROCONT-446
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Wolfgang Knauf
>
> bean-deployer_2_0.xsd:
>    <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
> =>should point. 
>    <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">
> The comment for a sample instance should also contain a schema location attribute:
>          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xmlns="urn:jboss:bean-deployer:2.0"
>             xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">
> ==================
> bean-deployer_1_0.xsd:
> The comment for a sample instance should point to the web schema location:
>          <deployment
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
>             xmlns="urn:jboss:bean-deployer">
> =================
> policy_1_0.xsd:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
> should be:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>
> =================
> bean-deployer_2_0.xsd raises validation errors in Eclipse:
> -rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
> -src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
> According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 13:31:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Sun, 21 Jun 2009 13:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7034) Outdated/missing
 schema files on website
In-Reply-To: <15960137.1245267836412.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27261627.1245605516432.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Wolfgang Knauf updated JBAS-7034:
---------------------------------

    Description: 
Some xsd files are missing or are outdated at http://www.jboss.org/j2ee/schema/

Please update from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/):

jboss-ds_5_0.xsd (missing)
jboss-web_5_1.xsd (missing)
jboss_common_5_1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.0.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-185 )
(some still do not validate because of invalid schema locations, so they must be updated again if https://jira.jboss.org/jira/browse/JBMETA-210 is fixed)

bean-deployer_1_0.xsd (missing)
bean-deployer_2_0.xsd (missing)
jboss-beans-common_2_0.xsd (missing)
policy_1_0.xsd (missing)
Note: they do not validate, too (invalid schema locations, and a (maybe false) validation error, see https://jira.jboss.org/jira/browse/JBMICROCONT-446 ), but they should be available on the website anyway.

  was:
Some xsd files are missing or are outdated at http://www.jboss.org/j2ee/schema/

Please update from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/):

jboss-ds_5_0.xsd (missing)
jboss-web_5_1.xsd (missing)
jboss_common_5_1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.0.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-185 )
(some still do not validate because of invalid schema locations, so they must be updated again if https://jira.jboss.org/jira/browse/JBMETA-210 is fixed)

bean-deployer_1_0.xsd (missing)
bean-deployer_2_0.xsd (missing)
jboss-beans-common_2_0.xsd (missing)
policy_1_0.xsd (missing)
Note: they do not validate, too (invalid schema locations, and a (maybe false) validation error), but they should be available on the website anyway.



> Outdated/missing schema files on website
> ----------------------------------------
>
>                 Key: JBAS-7034
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7034
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Wolfgang Knauf
>
> Some xsd files are missing or are outdated at http://www.jboss.org/j2ee/schema/
> Please update from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/):
> jboss-ds_5_0.xsd (missing)
> jboss-web_5_1.xsd (missing)
> jboss_common_5_1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
> jboss_5.1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
> jboss_5.0.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-185 )
> (some still do not validate because of invalid schema locations, so they must be updated again if https://jira.jboss.org/jira/browse/JBMETA-210 is fixed)
> bean-deployer_1_0.xsd (missing)
> bean-deployer_2_0.xsd (missing)
> jboss-beans-common_2_0.xsd (missing)
> policy_1_0.xsd (missing)
> Note: they do not validate, too (invalid schema locations, and a (maybe false) validation error, see https://jira.jboss.org/jira/browse/JBMICROCONT-446 ), but they should be available on the website anyway.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 17:07:07 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Sun, 21 Jun 2009 17:07:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-737) Duplicate bind
 element at injboss example
In-Reply-To: <29249137.1245618296598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13647544.1245618427013.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAOP-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473169#action_12473169 ] 

Flavia Rainone commented on JBAOP-737:
--------------------------------------

Thanks to Luciano Malagris for pointing this out :-)

> Duplicate bind element at injboss example
> -----------------------------------------
>
>                 Key: JBAOP-737
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-737
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>             Fix For: 2.1.2.GA
>
>
> There is a duplicate entry of the bind element at the jboss-aop.xml file of the injboss example (tutorial):
> http://www.jboss.org/jbossaop/docs/2.0.0.GA/docs/aspect-framework/examples/injboss/aopInJbossPackaging.html
> This needs to be fixed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 17:04:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Sun, 21 Jun 2009 17:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-737) Duplicate bind
 element at injboss example
Message-ID: <29249137.1245618296598.JavaMail.jira@cloud.prod.atl2.jboss.com>

Duplicate bind element at injboss example
-----------------------------------------

                 Key: JBAOP-737
                 URL: https://jira.jboss.org/jira/browse/JBAOP-737
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.1.GA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: 2.1.2.GA


There is a duplicate entry of the bind element at the jboss-aop.xml file of the injboss example (tutorial):
http://www.jboss.org/jbossaop/docs/2.0.0.GA/docs/aspect-framework/examples/injboss/aopInJbossPackaging.html

This needs to be fixed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 19:50:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Sun, 21 Jun 2009 19:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-738) Error for overloaded
 methods with Invocations and Joinpoint
Message-ID: <11375593.1245628256421.JavaMail.jira@cloud.prod.atl2.jboss.com>

Error for overloaded methods with Invocations and Joinpoint
-----------------------------------------------------------

                 Key: JBAOP-738
                 URL: https://jira.jboss.org/jira/browse/JBAOP-738
             Project: JBoss AOP
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.1.GA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone


JBoss AOP gets confused when, for a typed advice that not around, the advice method is overloaded and there is a version that receives an Invocation. So, for the example below:

public Object adendo(@JoinPoint MethodInvocation invocation,
			@Args Object[] args)
	throws Throwable {...}
	
       
public void adendo(@JoinPoint MethodExecution joinpoint,
			@Args Object[] args)
	throws Throwable {...}

JBoss AOP will complain of the version with Invocation, stating it is inappropriate for an advice of type before/after/whatever, while it should be able of finding the version that gets a MethodExecution and bind that version of " adendo" method.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 21:32:57 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Sun, 21 Jun 2009 21:32:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6449)
 InvokerAdaptorService
 overwrites existing SecurityContext and clears it after invocation
In-Reply-To: <20893098.1233747464875.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9795822.1245634377075.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Richard Kennard commented on JBAS-6449:
---------------------------------------

Confirming this bug still in 5.1.0.GA. It's very bad, as it makes it next to impossible to, say, check the depth of a queue...

RMIAdaptor server = (RMIAdaptor) new InitialContext().lookup( EjbUtils.lookupEnv( "core/jmx-connection" ) );
ObjectName objectName = new ObjectName( "jboss.messaging.destination:service=Queue,name=" + queue );
int queueDepth = 0;(Integer) server.getAttribute( objectName, "MessageCount" );

...this code works, but subsequent calls to EJBs all fail because the last line (server.getAttribute) clears the security context.

Is there a workaround?

> InvokerAdaptorService overwrites existing SecurityContext and clears it after invocation
> ----------------------------------------------------------------------------------------
>
>                 Key: JBAS-6449
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6449
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows Vista, JBoss 5.0.0 GA
>            Reporter: Michael Gronau
>
> The InvokerAdaptorService always creates a new SecurityContext even if there is already one created by components called earlier in invocation stack. After invoking the desired MBean method the SecurityContext will be cleared with a call to: SecurityActions.clearSecurityContext();
> This leads to several problems:
> In our project we have a secured EJB (annotated with @SecurityDomain) which is calling an MBean Service and a local (secured) EJB. After the invocation of the mbean there is no security context anymore which leads to an IllegalStateException "Security Context has not been set" thrown by RoleBasedAuthorizationInterceptorv2) when we try to call the local EJB.
> Following steps are possible to fix the problem:
> 1. call to SecurityActions.getSecurityContext();
> 2. if there is currently no SecurityContext create a new one and set it.
> 3. if there already is a SecurityContext set, do nothing.
> 4. call the mbean method.
> 5. only if we created the SecurityContext, we should clear it with SecurityActions.clearSecurityContext(), otherwise, do nothing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 21:36:56 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Sun, 21 Jun 2009 21:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6449)
 InvokerAdaptorService
 overwrites existing SecurityContext and clears it after invocation
In-Reply-To: <20893098.1233747464875.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19738061.1245634616900.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Richard Kennard commented on JBAS-6449:
---------------------------------------

I should further mention this problem was not present in JBoss 4.2.3.GA. The above code worked without problem (albeit using 'jboss.mq.destination.service' and 'QueueDepth')

> InvokerAdaptorService overwrites existing SecurityContext and clears it after invocation
> ----------------------------------------------------------------------------------------
>
>                 Key: JBAS-6449
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6449
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows Vista, JBoss 5.0.0 GA
>            Reporter: Michael Gronau
>
> The InvokerAdaptorService always creates a new SecurityContext even if there is already one created by components called earlier in invocation stack. After invoking the desired MBean method the SecurityContext will be cleared with a call to: SecurityActions.clearSecurityContext();
> This leads to several problems:
> In our project we have a secured EJB (annotated with @SecurityDomain) which is calling an MBean Service and a local (secured) EJB. After the invocation of the mbean there is no security context anymore which leads to an IllegalStateException "Security Context has not been set" thrown by RoleBasedAuthorizationInterceptorv2) when we try to call the local EJB.
> Following steps are possible to fix the problem:
> 1. call to SecurityActions.getSecurityContext();
> 2. if there is currently no SecurityContext create a new one and set it.
> 3. if there already is a SecurityContext set, do nothing.
> 4. call the mbean method.
> 5. only if we created the SecurityContext, we should clear it with SecurityActions.clearSecurityContext(), otherwise, do nothing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 02:32:57 2009
From: jira-events at lists.jboss.org (Osamu Yokomizo (JIRA))
Date: Mon, 22 Jun 2009 02:32:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32107598.1245652377163.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Osamu Yokomizo updated EJBTHREE-995:
------------------------------------

    Attachment: src.zip


This is source files.

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>         Attachments: src.zip
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 02:34:56 2009
From: jira-events at lists.jboss.org (Osamu Yokomizo (JIRA))
Date: Mon, 22 Jun 2009 02:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10921708.1245652496631.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Osamu Yokomizo updated EJBTHREE-995:
------------------------------------

    Attachment: sample.jar


This is jar(EJB and Client)

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>         Attachments: sample.jar, src.zip
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 03:36:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 22 Jun 2009 03:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1664) Ordering
 Group is broken
 on server restart when messages are paged and reloaded
Message-ID: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ordering Group is broken on server restart when messages are paged and reloaded
-------------------------------------------------------------------------------

                 Key: JBMESSAGING-1664
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.4.GA, 1.4.0.SP3.CP08
            Reporter: Howard Gao
            Assignee: Howard Gao
             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA


When messages are paged into the DB and reloaded on server restart, the strict is broken.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 03:50:57 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 22 Jun 2009 03:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2133) Drools-solver
 manual corrections from Yet another math programming consultant blog
Message-ID: <15744621.1245657057041.JavaMail.jira@cloud.prod.atl2.jboss.com>

Drools-solver manual corrections from Yet another math programming consultant blog
----------------------------------------------------------------------------------

                 Key: JBRULES-2133
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2133
             Project: JBoss Drools
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: drools-solver
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet
            Priority: Optional


http://yetanothermathprogrammingconsultant.blogspot.com/2009/06/simplex-method-description.html?showComment=1245656649020#c9186233704679009828

- The branch&bound section should mention about the unique feature that it provides bounds and hence an indication of the quality of the solution.

- The simplex  section is supposedly wrong (It's unclear how it can be corrected): "If the word Simplex was missing I would not recognize this is about the Simplex method. One big equation? (No word about not being suited to handle discrete variables)."

- "Local search starts from an initial solution and evolves that single solution into a better and better solution." should be "Local search starts from an initial solution and evolves that single solution, ussually into a better and better solution."


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 03:54:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 22 Jun 2009 03:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2133) Drools-solver
 manual corrections from Yet another math programming consultant blog
In-Reply-To: <15744621.1245657057041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <230969.1245657296531.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Geoffrey De Smet commented on JBRULES-2133:
-------------------------------------------

If no correction on the simplex section is given, I 'll probably remove it for now.

> Drools-solver manual corrections from Yet another math programming consultant blog
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2133
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2133
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Optional
>
> http://yetanothermathprogrammingconsultant.blogspot.com/2009/06/simplex-method-description.html?showComment=1245656649020#c9186233704679009828
> - The branch&bound section should mention about the unique feature that it provides bounds and hence an indication of the quality of the solution.
> - The simplex  section is supposedly wrong (It's unclear how it can be corrected): "If the word Simplex was missing I would not recognize this is about the Simplex method. One big equation? (No word about not being suited to handle discrete variables)."
> - "Local search starts from an initial solution and evolves that single solution into a better and better solution." should be "Local search starts from an initial solution and evolves that single solution, ussually into a better and better solution."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 02:32:56 2009
From: jira-events at lists.jboss.org (Osamu Yokomizo (JIRA))
Date: Mon, 22 Jun 2009 02:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5617215.1245652376937.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473193#action_12473193 ] 

Osamu Yokomizo commented on EJBTHREE-995:
-----------------------------------------

Hi , Andrew.

The reproduced program was put, and look, please.

1: deploy sample.jar
2: execute client SampleClient.
   SampleClient is in sample.jar. 

This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

server.log
====
...
15:05:36,406 INFO  [Server] JBoss (MX MicroKernel) [4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181439)] Started in 11s:891ms
15:06:00,859 INFO  [STDOUT] ut.begin():6
15:06:00,859 INFO  [STDOUT] afterBegin()
15:06:00,875 INFO  [STDOUT] afterBegin()
15:06:00,875 INFO  [STDOUT] afterBegin()
15:06:00,875 INFO  [STDOUT] beforeCompletion():
15:06:00,875 INFO  [STDOUT] beforeCompletion():
15:06:00,875 INFO  [STDOUT] beforeCompletion():
15:06:00,875 INFO  [STDOUT] afterCompletion():true
15:06:00,875 INFO  [STDOUT] afterCompletion():true
15:06:00,875 INFO  [STDOUT] afterCompletion():true
====


> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>         Attachments: src.zip
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 04:45:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 22 Jun 2009 04:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1639) Validate
 configuration values programmatically
In-Reply-To: <9257056.1244133116418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8077793.1245660356855.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil closed JBMESSAGING-1639.
------------------------------------

    Fix Version/s: 2.0.0.beta3
                       (was: 2.0.0)
       Resolution: Done


fixed in the trunk

> Validate configuration values programmatically
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1639
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1639
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0.beta3
>
>
> using XSD to validate configuration values make the schema more complex and error-prone (the error messages are hard to understand too).
> We should move to programmatic validation. E.g. in FileConfiguration, when we read the values from the configuration, we could add a validation step to check values (e.g. must be -1 or > 0 which is impossible to express in a XML Schema)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 03:01:07 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 22 Jun 2009 03:01:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11905023.1245654067523.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473197#action_12473197 ] 

Andrew Lee Rubinger commented on EJBTHREE-995:
----------------------------------------------

Thanks for the attachments, Osamu.  We've been looking for a failing case.  I'll see if I can port these to reproduce in AS 5.x as well.

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>         Attachments: sample.jar, src.zip
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 05:28:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 22 Jun 2009 05:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2134) Configure a custom
 termination, selector, accepter or forager: document how to in the manual
Message-ID: <3915765.1245662936924.JavaMail.jira@cloud.prod.atl2.jboss.com>

Configure a custom termination, selector, accepter or forager: document how to in the manual
--------------------------------------------------------------------------------------------

                 Key: JBRULES-2134
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2134
             Project: JBoss Drools
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: drools-solver
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet
            Priority: Minor


Is it possible?
I think it should be possible by writing your own MyAccepterConfig next to your own MyAccepter.
One of the examples should show how this works and the manual should show it too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 05:30:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 22 Jun 2009 05:30:56 -0400 (EDT)
Subject: [jboss-jira] 
 [JBoss JIRA] Commented: (JBRULES-1328) SelectorConfig, 
 AccepterConfig en other Config's aren't Serializable
 if they have a direct Selector/Accepter instance configured
In-Reply-To: <17195507.1195227678726.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9769564.1245663056570.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Geoffrey De Smet commented on JBRULES-1328:
-------------------------------------------

JBRULES-2134 will provide a better solution and the ability to put in a accepter in AccepterConfig etc should be removed

> SelectorConfig, AccepterConfig en other Config's aren't Serializable if they have a direct Selector/Accepter instance configured
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1328
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1328
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Optional
>
> Because AbstractAccepter references LocalSearchSolver references the drools RuleBase references stuff that isn't Serializable...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 08:47:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 22 Jun 2009 08:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1664) Ordering Group
 is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14023424.1245674876482.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao closed JBMESSAGING-1664.
-----------------------------------

    Resolution: Done


done

> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:05:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 22 Jun 2009 09:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1437) Browsers
 should iterate on queue
In-Reply-To: <33355941.1225819521109.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4560232.1245675956725.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil reassigned JBMESSAGING-1437:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Browsers should iterate on queue
> --------------------------------
>
>                 Key: JBMESSAGING-1437
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1437
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>         Attachments: patch-JBMESSAGING-1437.txt
>
>
> Currently the server browser implementation is taking a snapshot of the queue and browsing that. Instead we should implement an iterator on the queue which allows refs to be added or removed from the ends without affecting it.
> This is also necessary to allow failover for browsers which is very hard to implement with the current snapshot approach

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:34:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 22 Jun 2009 09:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-999) Remove deprecated
 classes or methods
Message-ID: <9740032.1245677696663.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remove deprecated classes or methods
------------------------------------

                 Key: JGRP-999
                 URL: https://jira.jboss.org/jira/browse/JGRP-999
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.0


Classes/methods annotated with @Deprecated (or @deprecated in the Javadocs) need to be removed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:26:10 2009
From: jira-events at lists.jboss.org (Juergen W (JIRA))
Date: Mon, 22 Jun 2009 09:26:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-115) Bug in
 AbstractEntityPersister for generated version properties
Message-ID: <24166695.1245677170570.JavaMail.jira@cloud.prod.atl2.jboss.com>

Bug in AbstractEntityPersister for generated version properties
---------------------------------------------------------------

                 Key: HIBERNATE-115
                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-115
             Project: Hibernate
          Issue Type: Bug
         Environment: Jboss 4.2.3 GA, Hibernate 3.3.1, MSSQL Server 2005, actual Merlia DB Driver 7.0.5
            Reporter: Juergen W
            Assignee: Steve Ebersole


Following problem:

we're using following configuration for our entities (dynamic-update="true" , dynamic-insert="true" , select-before-update="true", the version property is generated by the database and is read-only )

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping>
<class name="de.xxx.xxx.Angebot"  
   table="ANGeBot" 
   dynamic-update="true"  
   dynamic-insert="true" 
   select-before-update="true">
 
<id name="angbId" type="java.lang.Integer" column="ANGB_ID" unsaved-value="0">
	<generator class="identity"/>
</id>
     <version name="Timestamp" type="binary" column="ANGB_Timestamp" generated="always" insert="false" unsaved-value="undefined"/>  

	<property name="Aenderungsdatum" column="ANGB_Aenderungsdatum" type="java.util.Date" length="23"/>
	<property name="Aenderungsperson" column="ANGB_Aenderungsperson" type="java.lang.String" length="30"/>
	<property name="AnbieterAnsprechpartner" column="ANGB_Anbieter_Ansprechpartner" type="java.lang.String" length="100"/>

       ... additional props...
</class>
</hibernate-mapping>


If we made some changes to a row, hibernate should update only the "dirty fields" and NOT the version field. But hibernate tries to update the version property too, and thus we got the  db exception, the version column is not updateable.

Hibernate generates following updatestatement, if we change the field ANGB_ANBIETER_ANSPRECHPARTNER

 UPDATE
            V_AMVW_ANGEBOT
        SET
            ANGB_TIMESTAMP=?,    <----  THATs WRONG
            ANGB_ANBIETER_ANSPRECHPARTNER=?
        WHERE
            ANGB_ID=?
            AND ANGB_TIMESTAMP=?


I think, in the org.hibernate.persister.entity.AbstractEntityPersister in the method getPropertiesToUpdate() following "if statement" is missing if the version property is generated:

		if ( isVersioned()) {
			propsToUpdate[ getVersionProperty() ] =
				Versioning.isVersionIncrementRequired( dirtyProperties, hasDirtyCollection, getPropertyVersionability() );
		}


If I change the "if" statement to following:

		if ( isVersioned() && !isVersionPropertyGenerated()) {
			propsToUpdate[ getVersionProperty() ] =
				Versioning.isVersionIncrementRequired( dirtyProperties, hasDirtyCollection, getPropertyVersionability() );
		}

than it is working


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:04:10 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 22 Jun 2009 09:04:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1437) Browsers
 should iterate on queue
In-Reply-To: <33355941.1225819521109.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2504761.1245675850036.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil updated JBMESSAGING-1437:
-------------------------------------

    Attachment: patch-JBMESSAGING-1437.txt


A patch to have a "browser" consumer iterates directly on the queue rather than create a snapshot copy of it.

This code does not work when browsing a queue with large messages

> Browsers should iterate on queue
> --------------------------------
>
>                 Key: JBMESSAGING-1437
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1437
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>         Attachments: patch-JBMESSAGING-1437.txt
>
>
> Currently the server browser implementation is taking a snapshot of the queue and browsing that. Instead we should implement an iterator on the queue which allows refs to be added or removed from the ends without affecting it.
> This is also necessary to allow failover for browsers which is very hard to implement with the current snapshot approach

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:19:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Mon, 22 Jun 2009 09:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-739)
 NoMatchingAdviceException does not list @Joinpoint Parameters
Message-ID: <29353533.1245676796603.JavaMail.jira@cloud.prod.atl2.jboss.com>

NoMatchingAdviceException does not list @Joinpoint Parameters
-------------------------------------------------------------

                 Key: JBAOP-739
                 URL: https://jira.jboss.org/jira/browse/JBAOP-739
             Project: JBoss AOP
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.2.GA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: 2.2.0.GA


When using a before advice to intercept a void method execution, if the before advice has the wrong signature, JBoss AOP thrown a NoMatchingAdviceException stating that it would only accept @Arg and @Args parameters.
This exception's message should also list the possibility of using @JoinPoint parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 08:43:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 22 Jun 2009 08:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken
 on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10233010.1245674636560.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao commented on JBMESSAGING-1664:
-----------------------------------------

The reason why it doesn't work in case of paging is that when the server is restarted and start delivering messages, paged messages will be loaded from the DB and put to the queue. And the ordering group doesn't handle this case.
To fix it, we need to add the control during the loading of paged messages in PagingChannelSupport.loadPagedReferences():

...
      while (iter.hasNext())
      {
         ReferenceInfo info = (ReferenceInfo)iter.next();
         
         MessageReference ref = addFromRefInfo(info, refMap);
         
         monitor.registerMessage(ref);  ---------------this adds the message to the ordering group control.
...



> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 10:48:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 22 Jun 2009 10:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24984971.1245682136735.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai reassigned EJBTHREE-1852:
--------------------------------------

    Assignee: jaikiran pai


> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: jaikiran pai
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:00:04 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Mon, 22 Jun 2009 09:00:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1652) Convert build
 to use Maven repository
In-Reply-To: <20391798.1244809196438.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25249373.1245675604689.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andy Taylor closed JBMESSAGING-1652.
------------------------------------

    Resolution: Done


> Convert build to use Maven repository
> -------------------------------------
>
>                 Key: JBMESSAGING-1652
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1652
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> We should convert the build to use the Maven repository and Maven dependency checking rather than the old JBoss Repository.
> The rest of the build can stay with ant.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:55:57 2009
From: jira-events at lists.jboss.org (Jonathon Leibundguth (JIRA))
Date: Mon, 22 Jun 2009 09:55:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2135) Deadlock occurs
 in
 Multithreaded Environment NamedEntryPoint lock and AbstractWorkingMemory
 actionQueue sync block.
In-Reply-To: <28635049.1245678836810.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1344925.1245678958007.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jonathon Leibundguth commented on JBRULES-2135:
-----------------------------------------------

I believe something like this replaced method for AbstractWorkingMemory may resolve the issue, but I am not fully versed in the Drools Core code (pls don't kill me) - also this was a quick fix to unblock our project, there may be a more elegant impl., but point is to either move the execute() action outside of the sync block or find another avenue to resolve deadlock between actionQueue locking and NamedEntryPoint Reentrant lock:

    public void executeQueuedActions() {
    	// fill this so that execute is called outside of the sync block to avoid deadlock
    	Queue<WorkingMemoryAction> execQueue = new LinkedList<WorkingMemoryAction>();

    	synchronized ( this.actionQueue ) {
            if ( !this.actionQueue.isEmpty() && !evaluatingActionQueue ) {
                evaluatingActionQueue = true;
                WorkingMemoryAction action = null;
                while ( (action = actionQueue.poll()) != null ) {
                	execQueue.add(action);
                }
                evaluatingActionQueue = false;
            }
        }
        WorkingMemoryAction execAction = null;
        while ( (execAction = execQueue.poll()) != null ) {
            try {
            	execAction.execute( this );
            } catch ( Exception e ) {
                if( e instanceof RuntimeDroolsException ) {
                    // rethrow the exception
                    throw ((RuntimeDroolsException)e);
                } else {
                    System.err.println("************************************************");
                    System.err.println("Exception caught while executing action: "+execAction.toString());
                    e.printStackTrace();
                }
            }
        }
    	
    }

> Deadlock occurs in Multithreaded Environment NamedEntryPoint lock and AbstractWorkingMemory actionQueue sync block.
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2135
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2135
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.0.1.FINAL
>         Environment: java version "1.6.0_0"
> OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu7)
> OpenJDK Client VM (build 14.0-b08, mixed mode, sharing)
>            Reporter: Jonathon Leibundguth
>            Assignee: Mark Proctor
>            Priority: Critical
>
> While running drools using fireUntilHalt in multithreaded environment, the following situation results in deadlock:
> Thread A (Drools' Thread):  AbstractWorkingMemory method executeQueuedActions() locks actionQueue:
> synchronized ( this.actionQueue )
> Calls action.execute( this ) for each item in queue, in this case WorkingMemoryReteExpireAction to expire an event object.  The  WorkingMemoryReteExpireAction tries to obtain the lock in NamedEntryPoint during call to retract().
> Thread B (User's Thread):  attempts to execute a NamedEntryPoint insert() action simultaneously with the above.  The thread obtains the NamedEntryPoint lock and blocks waiting for the lock on actionQueue.
> Deadlock:
> Thread A is blocked waiting for NamedEntryPoint lock, owned by Thread B.
> Thread B is blocked waiting for lock on actionQueue, owned by Thread A.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:15:07 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Mon, 22 Jun 2009 09:15:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1612) Provide a
 complete JCA Parmeters override
In-Reply-To: <23605475.1241104013618.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9338040.1245676507366.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andy Taylor reassigned JBMESSAGING-1612:
----------------------------------------

    Assignee: Andy Taylor  (was: Clebert Suconic)


> Provide a complete JCA Parmeters override
> -----------------------------------------
>
>                 Key: JBMESSAGING-1612
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1612
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:53:56 2009
From: jira-events at lists.jboss.org (Jonathon Leibundguth (JIRA))
Date: Mon, 22 Jun 2009 09:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2135) Deadlock occurs in
 Multithreaded Environment NamedEntryPoint lock and AbstractWorkingMemory
 actionQueue sync block.
Message-ID: <28635049.1245678836810.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deadlock occurs in Multithreaded Environment NamedEntryPoint lock and AbstractWorkingMemory actionQueue sync block.
-------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2135
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2135
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core (fusion)
    Affects Versions: 5.0.1.FINAL
         Environment: java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu7)
OpenJDK Client VM (build 14.0-b08, mixed mode, sharing)
            Reporter: Jonathon Leibundguth
            Assignee: Mark Proctor
            Priority: Critical


While running drools using fireUntilHalt in multithreaded environment, the following situation results in deadlock:

Thread A (Drools' Thread):  AbstractWorkingMemory method executeQueuedActions() locks actionQueue:

synchronized ( this.actionQueue )

Calls action.execute( this ) for each item in queue, in this case WorkingMemoryReteExpireAction to expire an event object.  The  WorkingMemoryReteExpireAction tries to obtain the lock in NamedEntryPoint during call to retract().

Thread B (User's Thread):  attempts to execute a NamedEntryPoint insert() action simultaneously with the above.  The thread obtains the NamedEntryPoint lock and blocks waiting for the lock on actionQueue.

Deadlock:
Thread A is blocked waiting for NamedEntryPoint lock, owned by Thread B.
Thread B is blocked waiting for lock on actionQueue, owned by Thread A.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:10:57 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 22 Jun 2009 11:10:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2308) More Selenium
	Test
In-Reply-To: <27448854.1234455644582.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14284308.1245683457056.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473275#action_12473275 ] 

Viliam Rockai commented on JBPORTAL-2308:
-----------------------------------------

i've added a test for input validation for nearly all inputs in portal.

i didn't add tests for:
search inputs
samples

> More Selenium Test
> ------------------
>
>                 Key: JBPORTAL-2308
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2308
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>
> This is a wrapper task.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:37:07 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 22 Jun 2009 09:37:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1505) Optimise
 multiple message selectors on a queue
In-Reply-To: <5128840.1234454804372.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30493492.1245677827589.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil reassigned JBMESSAGING-1505:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Optimise multiple message selectors on a queue
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1505
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1505
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> In the case where there are multiple message selectors on a queue, the entire queue needs to be scanned for each delivery.
> We can optimise this by adding indexes on the queue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 10:34:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 22 Jun 2009 10:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBMESSAGING-1663) Release JBoss
 Messaging 2.0.0.Beta3
Message-ID: <31574340.1245681297366.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Clebert Suconic deleted JBMESSAGING-1663:
-----------------------------------------


> Release JBoss Messaging 2.0.0.Beta3
> -----------------------------------
>
>                 Key: JBMESSAGING-1663
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1663
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 10:54:59 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 22 Jun 2009 10:54:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7659546.1245682499494.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

jaikiran pai updated EJBTHREE-1852:
-----------------------------------

    Assignee:     (was: jaikiran pai)


> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:45:56 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 22 Jun 2009 11:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBLOGGING-18) Creating a logger
 is privileged, but no doPrivilieged exists
In-Reply-To: <28909706.1245685436790.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28904142.1245685556695.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

David Lloyd closed JBLOGGING-18.
--------------------------------

    Resolution: Done


> Creating a logger is privileged, but no doPrivilieged exists
> ------------------------------------------------------------
>
>                 Key: JBLOGGING-18
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-18
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logmanager
>    Affects Versions: 1.0.0.GA-jboss-logmanager
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.1.0.CR3-jboss-logmanager
>
>
> Failures seen when security manager is enabled during test suite.  Logger construction calls setLevel() which is privileged, so logger creation must be privileged.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 10:52:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 22 Jun 2009 10:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7044)
 "java.io.NotSerializableException: java.util.HashMap$KeySet" error when
 ManagementView.getComponentTypes() is called over a remote connection
Message-ID: <23794448.1245682376767.JavaMail.jira@cloud.prod.atl2.jboss.com>

"java.io.NotSerializableException: java.util.HashMap$KeySet" error when ManagementView.getComponentTypes() is called over a remote connection
---------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7044
                 URL: https://jira.jboss.org/jira/browse/JBAS-7044
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Scott M Stark
             Fix For: JBossAS-5.2.0.Beta1


Exception in thread "main" org.jboss.remoting.InvocationFailureException: Unable to perform invocation; nested exception is:
        java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: java.util.HashMap$KeySet
        at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:142)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:891)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentTypes(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:165)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:118)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:112)
Caused by: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: java.util.HashMap$KeySet
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
        at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
        at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
        at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentTypes(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:165)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:118)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:112)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 9 more
Caused by: java.io.NotSerializableException: java.util.HashMap$KeySet
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
        at org.jboss.aop.joinpoint.InvocationResponse.writeExternal(InvocationResponse.java:100)
        at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1421)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1390)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:120)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:95)
        at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120)
        at org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:75)
        at org.jboss.remoting.transport.socket.ServerThread.versionedWrite(ServerThread.java:1006)
        at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:783)
        at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
        at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:524)
        at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:02:57 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 22 Jun 2009 11:02:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2223) create a
 hudson build for windows/IE testing
In-Reply-To: <4748061.1225462581379.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25380949.1245682977236.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473272#action_12473272 ] 

Viliam Rockai commented on JBPORTAL-2223:
-----------------------------------------

i've renamed the job to http://hudson.qa.jboss.com/hudson/view/JBoss Portal/job/jboss-portal-2.7-selenium-winIE7-
i wasn't able to find why i can't delete the workspace, this was the easiest way.

unfortunatelly, lots of work must be done until i make the suite stable.

anyway, we're not building portal on IE machine. i do the build in this job:
http://hudson.qa.jboss.com/hudson/view/JBoss%20Portal/job/jboss-portal-2.7-selenium-tests/
save the bundle on qa machine, and IE7 job just make use of this bundle.

is it enough or should i spend time on building of portal under windows?

> create a hudson build for windows/IE testing
> --------------------------------------------
>
>                 Key: JBPORTAL-2223
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2223
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:16:57 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 22 Jun 2009 11:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4493575.1245683817230.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf reassigned EJBTHREE-1852:
---------------------------------------

    Assignee: Carlo de Wolf


> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: Carlo de Wolf
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:08:57 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 22 Jun 2009 11:08:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2301) add perf test
	in selenium
In-Reply-To: <29209307.1233763904828.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26443515.1245683337097.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473274#action_12473274 ] 

Viliam Rockai commented on JBPORTAL-2301:
-----------------------------------------

i have difficulties with creating the dashboard with the portlet which was working for chris
https://jira.jboss.org/jira/browse/JBPORTAL-2040 

it make use of a class which seems to be missing in current portal 
http://docs.jboss.org/jbportal/v2.7.0.CR1/javadoc-bundle/cms/org/jboss/portal/cms/hibernate/state/Tools.html

anyway, i've written an e-mail to chris, hope we'll be able to solve it soon.

> add perf test in selenium
> -------------------------
>
>                 Key: JBPORTAL-2301
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2301
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core, Portal QA
>    Affects Versions: 2.7.1 Final
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>             Fix For: 2.8 Final
>
>
> Here what I think you need to do for simple perf testsuite. Let's create one for dashboard:
> 1. Add a mechanism to add 10K users with "user" role in database. user1, user2....user9999. It might be easier to write a sql script. See which one you can crunch easily.
> 2. Create a new dashboard test case, which logs in as each user that you created and add couple of more portlets in user's dashboard. Again sql script might be easier if there are not too many constraints to satisfy.
> 3. Add a new testcase which logs in as one of the user, goes to dashboard. Record the time taken as user goes through it.
> If I needed, I will write a smartfrog component which simulates about 1K users hitting portal and each user going through her dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:43:56 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 22 Jun 2009 11:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-18) Creating a logger
 is privileged, but no doPrivilieged exists
Message-ID: <28909706.1245685436790.JavaMail.jira@cloud.prod.atl2.jboss.com>

Creating a logger is privileged, but no doPrivilieged exists
------------------------------------------------------------

                 Key: JBLOGGING-18
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-18
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-logmanager
    Affects Versions: 1.0.0.GA-jboss-logmanager
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 1.1.0.CR3-jboss-logmanager


Failures seen when security manager is enabled during test suite.  Logger construction calls setLevel() which is privileged, so logger creation must be privileged.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:16:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 22 Jun 2009 11:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-2380) add dnd test to
 Dashboard test case
In-Reply-To: <2223063.1240588306874.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15349460.1245683816896.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Viliam Rockai resolved JBPORTAL-2380.
-------------------------------------

    Resolution: Done


> add dnd test to Dashboard test case
> -----------------------------------
>
>                 Key: JBPORTAL-2380
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2380
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:18:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 22 Jun 2009 11:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2392) Selenium tests
	for XSS
In-Reply-To: <23069268.1242226847011.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31110396.1245683936662.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473278#action_12473278 ] 

Viliam Rockai commented on JBPORTAL-2392:
-----------------------------------------

i've added input validation tests for nearly all inputs in portal, checking for validation error message to be present on the screen after pressing relevant submit button.

i didn't add input validation for samples page and search inputs.

still waiting for last fixes from chris, probably some assert messages (in assert.properties) would have to be tweaked

> Selenium tests for XSS
> ----------------------
>
>                 Key: JBPORTAL-2392
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2392
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal QA
>            Reporter: Viliam Rockai
>            Assignee: Viliam Rockai
>
> Testing XSS on inputs in portal GUI had to be implemented.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:49:56 2009
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Mon, 22 Jun 2009 11:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2223) create a
 hudson build for windows/IE testing
In-Reply-To: <4748061.1225462581379.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2681711.1245685796577.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473286#action_12473286 ] 

Prabhat Jha commented on JBPORTAL-2223:
---------------------------------------

No need to spend time on building it on windows.

> create a hudson build for windows/IE testing
> --------------------------------------------
>
>                 Key: JBPORTAL-2223
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2223
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 12:26:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 22 Jun 2009 12:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2308) More Selenium
	Test
In-Reply-To: <27448854.1234455644582.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10901210.1245688016636.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473297#action_12473297 ] 

Viliam Rockai commented on JBPORTAL-2308:
-----------------------------------------

search users in admin interface
search users in role members in admin interface
search in cms

> More Selenium Test
> ------------------
>
>                 Key: JBPORTAL-2308
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2308
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>
> This is a wrapper task.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 12:24:56 2009
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Mon, 22 Jun 2009 12:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2308) More Selenium
	Test
In-Reply-To: <27448854.1234455644582.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28519891.1245687896536.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473296#action_12473296 ] 

Prabhat Jha commented on JBPORTAL-2308:
---------------------------------------

anything in samples doesn't need to be XSS validated.

Where is "search inputs"?



> More Selenium Test
> ------------------
>
>                 Key: JBPORTAL-2308
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2308
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>
> This is a wrapper task.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 16:04:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 22 Jun 2009 16:04:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1728584.1245701097019.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-6888:
---------------------------------


I've upgraded my local workspace to  use AOP 2.1.2.GA and still issues with aoptest.sar.  Specifically,
2009-06-22 14:26:49,566 INFO  [org.jboss.test.aop.bean.AOPTester] (HDScanner) RUNNING TEST BASIC
2009-06-22 14:26:49,567 ERROR [org.jboss.test.aop.bean.AOPTester] (HDScanner) failed
java.lang.RuntimeException: POJO is not instanceof Advised
        at org.jboss.test.aop.bean.AOPTester.testBasic(AOPTester.java:110)
        at org.jboss.test.aop.bean.AOPTester.startService(AOPTester.java:83)

I'll look at all the tests in the description of this JIRA to see what errors are now being encountered.

> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Flavia Rainone
>         Attachments: server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 16:08:56 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 22 Jun 2009 16:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBLOGGING-19) New formatters
 don't print stack traces
In-Reply-To: <5800232.1245701336575.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9083916.1245701336759.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

David Lloyd closed JBLOGGING-19.
--------------------------------

    Resolution: Done


> New formatters don't print stack traces
> ---------------------------------------
>
>                 Key: JBLOGGING-19
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-19
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logmanager
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.1.0.CR3-jboss-logmanager
>
>
> The new logmanager formatter for the message string does not output stack traces, making debugging rather interesting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 10:48:57 2009
From: jira-events at lists.jboss.org (Steve Ebersole (JIRA))
Date: Mon, 22 Jun 2009 10:48:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (HIBERNATE-115) Bug in
 AbstractEntityPersister for generated version properties
In-Reply-To: <24166695.1245677170570.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12347916.1245682137843.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Steve Ebersole closed HIBERNATE-115.
------------------------------------

    Resolution: Rejected


This is not true.  The version field should be updated on any state change.

> Bug in AbstractEntityPersister for generated version properties
> ---------------------------------------------------------------
>
>                 Key: HIBERNATE-115
>                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-115
>             Project: Hibernate
>          Issue Type: Bug
>         Environment: Jboss 4.2.3 GA, Hibernate 3.3.1, MSSQL Server 2005, actual Merlia DB Driver 7.0.5
>            Reporter: Juergen W
>            Assignee: Steve Ebersole
>
> Following problem:
> we're using following configuration for our entities (dynamic-update="true" , dynamic-insert="true" , select-before-update="true", the version property is generated by the database and is read-only )
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
> "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
> <hibernate-mapping>
> <class name="de.xxx.xxx.Angebot"  
>    table="ANGeBot" 
>    dynamic-update="true"  
>    dynamic-insert="true" 
>    select-before-update="true">
>  
> <id name="angbId" type="java.lang.Integer" column="ANGB_ID" unsaved-value="0">
> 	<generator class="identity"/>
> </id>
>      <version name="Timestamp" type="binary" column="ANGB_Timestamp" generated="always" insert="false" unsaved-value="undefined"/>  
> 	<property name="Aenderungsdatum" column="ANGB_Aenderungsdatum" type="java.util.Date" length="23"/>
> 	<property name="Aenderungsperson" column="ANGB_Aenderungsperson" type="java.lang.String" length="30"/>
> 	<property name="AnbieterAnsprechpartner" column="ANGB_Anbieter_Ansprechpartner" type="java.lang.String" length="100"/>
>        ... additional props...
> </class>
> </hibernate-mapping>
> If we made some changes to a row, hibernate should update only the "dirty fields" and NOT the version field. But hibernate tries to update the version property too, and thus we got the  db exception, the version column is not updateable.
> Hibernate generates following updatestatement, if we change the field ANGB_ANBIETER_ANSPRECHPARTNER
>  UPDATE
>             V_AMVW_ANGEBOT
>         SET
>             ANGB_TIMESTAMP=?,    <----  THATs WRONG
>             ANGB_ANBIETER_ANSPRECHPARTNER=?
>         WHERE
>             ANGB_ID=?
>             AND ANGB_TIMESTAMP=?
> I think, in the org.hibernate.persister.entity.AbstractEntityPersister in the method getPropertiesToUpdate() following "if statement" is missing if the version property is generated:
> 		if ( isVersioned()) {
> 			propsToUpdate[ getVersionProperty() ] =
> 				Versioning.isVersionIncrementRequired( dirtyProperties, hasDirtyCollection, getPropertyVersionability() );
> 		}
> If I change the "if" statement to following:
> 		if ( isVersioned() && !isVersionPropertyGenerated()) {
> 			propsToUpdate[ getVersionProperty() ] =
> 				Versioning.isVersionIncrementRequired( dirtyProperties, hasDirtyCollection, getPropertyVersionability() );
> 		}
> than it is working

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 10:46:59 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 22 Jun 2009 10:46:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31563199.1245682019160.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473264#action_12473264 ] 

jaikiran pai commented on EJBTHREE-1852:
----------------------------------------

I'll try to reproduce this with the default interceptors. Thanks for letting us know.


> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:14:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 22 Jun 2009 11:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2311) CMS tests with
	workflow on
In-Reply-To: <775677.1234458884428.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3552008.1245683696934.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473276#action_12473276 ] 

Viliam Rockai commented on JBPORTAL-2311:
-----------------------------------------

i wanted to resolve this issue, but i have found that the job has some problems lately:
http://hudson.qa.jboss.com/hudson/view/JBoss%20Portal/job/jboss-portal-2.7-workflow-selenium-tests/

i will look at that

> CMS tests with workflow on
> --------------------------
>
>                 Key: JBPORTAL-2311
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2311
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 16:17:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 22 Jun 2009 16:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6889) tests in
 tests-aop-scoped failing with IBM JDK
In-Reply-To: <7099808.1242045886541.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16115752.1245701876966.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-6889:
---------------------------------


Upgrading my local workspace with 2.1.0.GA, still see errors in these tests:
Caused by: java.lang.ExceptionInInitializerError
        at java.lang.J9VMInternals.initialize(J9VMInternals.java:218)
        at org.jboss.test.aop.jdk15annotated.ScopedAnnotatedTester.testCompostition(ScopedAnnotatedTester.java:144)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
Caused by: java.lang.NullPointerException
        at org.jboss.aop.instrument.JoinPointGenerator.findAdvisedField(JoinPointGenerator.java:499)
        at org.jboss.aop.instrument.JoinPointGenerator.&lt;init&gt;(JoinPointGenerator.java:187)
        at org.jboss.aop.instrument.MethodJoinPointGenerator.&lt;init&gt;(MethodJoinPointGenerator.java:74)
        at org.jboss.aop.GeneratedClassAdvisor$ClassAdvisorStrategy.getJoinPointGenerator(GeneratedClassAdvisor.java:1311)
        at org.jboss.aop.GeneratedClassAdvisor.getJoinPointGenerator(GeneratedClassAdvisor.java:778)
        at org.jboss.aop.GeneratedClassAdvisor.fullWorkFinalizeMethodChain(GeneratedClassAdvisor.java:632)
        at org.jboss.aop.GeneratedClassAdvisor.finalizeMethodChain(GeneratedClassAdvisor.java:596)
        at org.jboss.aop.GeneratedClassAdvisor.finalizeChains(GeneratedClassAdvisor.java:577)
        at org.jboss.aop.ClassAdvisor.createInterceptorChains(ClassAdvisor.java:609)
        at org.jboss.aop.GeneratedClassAdvisor.access$201(GeneratedClassAdvisor.java:65)
        at org.jboss.aop.GeneratedClassAdvisor$ClassAdvisorStrategy.createInterceptorChains(GeneratedClassAdvisor.java:1303)
        at org.jboss.aop.GeneratedClassAdvisor.createInterceptorChains(GeneratedClassAdvisor.java:407)


> tests in tests-aop-scoped failing with IBM JDK
> ----------------------------------------------
>
>                 Key: JBAS-6889
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6889
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: TEST-org.jboss.test.aop.test.ScopedAnnotatedTestCase-aop-scoped.xml
>
>
> Tests in the tests-aop-scoped target of JBoss AS testsuite are failing.
> The tests are:
> org.jboss.test.aop.test.ScopedAnnotatedTestCase
> org.jboss.test.aop.test.ScopedAttachUnitTestCase
> org.jboss.test.aop.test.ScopedEarWithClassesInWebInfTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseLoadedScopedNoParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseLoadedScopedParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseNotLoadedScopedNoParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseNotLoadedScopedParentDelegationTestCase
> org.jboss.test.aop.test.ScopedUnitTestCase
> org.jboss.test.aop.test.ScopedWovenDependencyTestCase
> The error message is:
> javax.management.RuntimeErrorException
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:182)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: java.lang.ExceptionInInitializerError
> 	at java.lang.J9VMInternals.initialize(J9VMInternals.java:216)
> 	at org.jboss.test.aop.jdk15annotated.ScopedAnnotatedTester.testBinding(ScopedAnnotatedTester.java:50)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.aop.Domain$1.run(Domain.java:124)
> 	at org.jboss.aop.Domain$1.run(Domain.java:121)
> 	at java.security.AccessController.doPrivileged(AccessController.java:197)
> 	at org.jboss.aop.Domain.getDomainName(Domain.java:119)
> 	at org.jboss.test.aop.jdk15annotated.POJO$POJOAdvisor.initialise(POJO$POJOAdvisor.java)
> 	at org.jboss.test.aop.jdk15annotated.POJO$POJOAdvisor.<init>(POJO$POJOAdvisor.java)
> 	at org.jboss.test.aop.jdk15annotated.POJO.<clinit>(POJO.java)
> 	at java.lang.J9VMInternals.initializeImpl(Native Method)
> 	at java.lang.J9VMInternals.initialize(J9VMInternals.java:194)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 16:44:56 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Mon, 22 Jun 2009 16:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1853) NPE upon
 lookup of errorneous EJB
In-Reply-To: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16458639.1245703496485.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473325#action_12473325 ] 

Ondrej ?i?ka commented on EJBTHREE-1853:
----------------------------------------

(20:48:52) ALR: ozizka: Please file a JIRA for *ANY* NPEs encountered
(20:49:02) ALR: As they should instead be a descriptive failure
(20:49:21) ALR: Even though yours is wrapped w/ some description, it doesn't say why.

> NPE upon lookup of errorneous EJB
> ---------------------------------
>
>                 Key: EJBTHREE-1853
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Ondrej ?i?ka
>         Attachments: EJBlookup-NPE.zip, log.txt
>
>
> When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.
> Steps to reproduce:
> 1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
> 2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
>     This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.
> Upon ctx.lookup(), the NPE occurs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 18:49:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 22 Jun 2009 18:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1853) NPE upon lookup
 of errorneous EJB
In-Reply-To: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15424238.1245710997011.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Andrew Lee Rubinger updated EJBTHREE-1853:
------------------------------------------

    Environment: 
JBAS:  AS 5.1.0  (from the JBPAPP branch)
Sun JDK jdk1.5.0_17

  was:
JBAS:  jboss-5.0.0.Beta  (from the JBPAPP branch)
Sun JDK jdk1.5.0_17



Probably some sort of assertion in the proxy code, instead of NPE, as well as a jboss-metadata validation check (in the post-processing chain) that @Remote/@Local contains an interface would be appropriate.

> NPE upon lookup of errorneous EJB
> ---------------------------------
>
>                 Key: EJBTHREE-1853
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBAS:  AS 5.1.0  (from the JBPAPP branch)
> Sun JDK jdk1.5.0_17
>            Reporter: Ondrej ?i?ka
>            Assignee: Andrew Lee Rubinger
>         Attachments: EJBlookup-NPE.zip, log.txt
>
>
> When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.
> Steps to reproduce:
> 1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
> 2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
>     This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.
> Upon ctx.lookup(), the NPE occurs.
> ----------------
> The EJB has:
> public interface Counter { }
> @Remote
> public interface CounterRemote extends Counter { }
> @Stateful
> @Remote(CounterBean.class)
> public class CounterBean implements Counter { }
> -------
> The client jar contains (incomplete list):
> public interface Counter { }
> @Stateful
> public class CounterBean implements Counter { }
> (this wild combination arose when testing :)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 17:26:56 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Mon, 22 Jun 2009 17:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1853) NPE upon lookup
 of errorneous EJB
In-Reply-To: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23623875.1245706016787.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ondrej ?i?ka reassigned EJBTHREE-1853:
--------------------------------------

    Assignee: Andrew Lee Rubinger


> NPE upon lookup of errorneous EJB
> ---------------------------------
>
>                 Key: EJBTHREE-1853
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBAS:  jboss-5.0.0.Beta  (from the JBPAPP branch)
> Sun JDK jdk1.5.0_17
>            Reporter: Ondrej ?i?ka
>            Assignee: Andrew Lee Rubinger
>         Attachments: EJBlookup-NPE.zip, log.txt
>
>
> When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.
> Steps to reproduce:
> 1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
> 2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
>     This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.
> Upon ctx.lookup(), the NPE occurs.
> ----------------
> The EJB has:
> public interface Counter { }
> @Remote
> public interface CounterRemote extends Counter { }
> @Stateful
> @Remote(CounterBean.class)
> public class CounterBean implements Counter { }
> -------
> The client jar contains (incomplete list):
> public interface Counter { }
> @Stateful
> public class CounterBean implements Counter { }
> (this wild combination arose when testing :)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 16:08:56 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 22 Jun 2009 16:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-19) New formatters
 don't print stack traces
Message-ID: <5800232.1245701336575.JavaMail.jira@cloud.prod.atl2.jboss.com>

New formatters don't print stack traces
---------------------------------------

                 Key: JBLOGGING-19
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-19
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-logmanager
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 1.1.0.CR3-jboss-logmanager


The new logmanager formatter for the message string does not output stack traces, making debugging rather interesting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 16:32:56 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Mon, 22 Jun 2009 16:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1853) NPE upon lookup
 of errorneous EJB
Message-ID: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE upon lookup of errorneous EJB
---------------------------------

                 Key: EJBTHREE-1853
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Ondrej ?i?ka


When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.

Steps to reproduce:
1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
    This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.

Upon ctx.lookup(), the NPE occurs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 16:58:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 22 Jun 2009 16:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <31498429.1245704336539.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-7032:
---------------------------------


John, not sure if you saw my comment in the referenced forum post but I cannot reproduce this error when deploying via the console.  Is there more information about your environment you can provide as I'm interested to know how you got into this state

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 16:42:56 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Mon, 22 Jun 2009 16:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1853) NPE upon lookup
 of errorneous EJB
In-Reply-To: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16511485.1245703376991.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ondrej ?i?ka updated EJBTHREE-1853:
-----------------------------------

    Attachment: log.txt


Stack trace. Also contains mvn exec command skeleton.

> NPE upon lookup of errorneous EJB
> ---------------------------------
>
>                 Key: EJBTHREE-1853
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Ondrej ?i?ka
>         Attachments: EJBlookup-NPE.zip, log.txt
>
>
> When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.
> Steps to reproduce:
> 1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
> 2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
>     This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.
> Upon ctx.lookup(), the NPE occurs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 16:56:56 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Mon, 22 Jun 2009 16:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1853) NPE upon lookup
 of errorneous EJB
In-Reply-To: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9243431.1245704216877.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ondrej ?i?ka updated EJBTHREE-1853:
-----------------------------------

    Environment: 
JBAS:  jboss-5.0.0.Beta  (from the JBPAPP branch)
Sun JDK jdk1.5.0_17
    Description: 
When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.

Steps to reproduce:
1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
    This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.

Upon ctx.lookup(), the NPE occurs.

----------------

The EJB has:

public interface Counter { }

@Remote
public interface CounterRemote extends Counter { }

@Stateful
@Remote(CounterBean.class)
public class CounterBean implements Counter { }

-------

The client jar contains (incomplete list):

public interface Counter { }

@Stateful
public class CounterBean implements Counter { }

(this wild combination arose when testing :)

  was:
When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.

Steps to reproduce:
1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
    This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.

Upon ctx.lookup(), the NPE occurs.



> NPE upon lookup of errorneous EJB
> ---------------------------------
>
>                 Key: EJBTHREE-1853
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBAS:  jboss-5.0.0.Beta  (from the JBPAPP branch)
> Sun JDK jdk1.5.0_17
>            Reporter: Ondrej ?i?ka
>         Attachments: EJBlookup-NPE.zip, log.txt
>
>
> When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.
> Steps to reproduce:
> 1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
> 2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
>     This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.
> Upon ctx.lookup(), the NPE occurs.
> ----------------
> The EJB has:
> public interface Counter { }
> @Remote
> public interface CounterRemote extends Counter { }
> @Stateful
> @Remote(CounterBean.class)
> public class CounterBean implements Counter { }
> -------
> The client jar contains (incomplete list):
> public interface Counter { }
> @Stateful
> public class CounterBean implements Counter { }
> (this wild combination arose when testing :)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 17:26:56 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Mon, 22 Jun 2009 17:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1853) NPE upon
 lookup of errorneous EJB
In-Reply-To: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <330704.1245706016640.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473332#action_12473332 ] 

Ondrej ?i?ka commented on EJBTHREE-1853:
----------------------------------------

By the way, after undeployment of the EJB (probably successful - not listed in JMX console), still there are traces of it in the JNDI namespace:

Global JNDI Namespace
...
  +- CounterBean (class: org.jnp.interfaces.NamingContext)
  |   +- remote-ejbtest.stateful.bean.CounterBean (class: Proxy for: ejbtest.stateful.bean.CounterBean)
  |   +- remote (class: Proxy for: ejbtest.stateful.bean.CounterBean)

This shouldn't happen either, should it?

> NPE upon lookup of errorneous EJB
> ---------------------------------
>
>                 Key: EJBTHREE-1853
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBAS:  jboss-5.0.0.Beta  (from the JBPAPP branch)
> Sun JDK jdk1.5.0_17
>            Reporter: Ondrej ?i?ka
>         Attachments: EJBlookup-NPE.zip, log.txt
>
>
> When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.
> Steps to reproduce:
> 1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
> 2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
>     This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.
> Upon ctx.lookup(), the NPE occurs.
> ----------------
> The EJB has:
> public interface Counter { }
> @Remote
> public interface CounterRemote extends Counter { }
> @Stateful
> @Remote(CounterBean.class)
> public class CounterBean implements Counter { }
> -------
> The client jar contains (incomplete list):
> public interface Counter { }
> @Stateful
> public class CounterBean implements Counter { }
> (this wild combination arose when testing :)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 16:34:56 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Mon, 22 Jun 2009 16:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1853) NPE upon lookup
 of errorneous EJB
In-Reply-To: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16995551.1245702896491.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ondrej ?i?ka updated EJBTHREE-1853:
-----------------------------------

    Attachment: EJBlookup-NPE.zip


EJB, client, and Maven projects for both.

> NPE upon lookup of errorneous EJB
> ---------------------------------
>
>                 Key: EJBTHREE-1853
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Ondrej ?i?ka
>         Attachments: EJBlookup-NPE.zip
>
>
> When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.
> Steps to reproduce:
> 1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
> 2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
>     This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.
> Upon ctx.lookup(), the NPE occurs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 22:23:56 2009
From: jira-events at lists.jboss.org (Dickson Lui (JIRA))
Date: Mon, 22 Jun 2009 22:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7045) Request to have
 examples / steps to setup simple clustering
Message-ID: <1655375.1245723836613.JavaMail.jira@cloud.prod.atl2.jboss.com>

Request to have examples / steps to setup simple clustering
-----------------------------------------------------------

                 Key: JBAS-7045
                 URL: https://jira.jboss.org/jira/browse/JBAS-7045
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Docs/Clustering Guide
         Environment: Documentation
            Reporter: Dickson Lui
            Priority: Optional


Suggestion for Docs/Clustering Guide

at least one full steps example for a simple clustering setup; steps by steps to setup the simple one that help the new user a lot. 

1. first step to do (  2 JBoss running in 2 machines; assume normal installation except for clustering?)

2. after it works fine individually, next step to do ( what???? )

3. next step, ....

4. Finally, how to test the clustering.


I think the original document is a kind of definition. I think the end user mostly want to know how to set and then deeply understand the details if they need.

I hope that all documentation could have more examples / steps to show the end user to implement the specific configuration. Thanks in advance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 00:59:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 23 Jun 2009 00:59:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6777) 'interleaving' prop
 on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15996071.1245733197932.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-6777.
---------------------------------

    Resolution: Partially Completed


To be able to update the interleaving value requires a deployment restart. I have updated the activationPolicy to be DEPLOYMENT_RESTART.

> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 01:05:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 23 Jun 2009 01:05:56 -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: <20182267.1245733556754.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Howard Gao updated JBMESSAGING-1661:
------------------------------------

    Fix Version/s: 1.4.5.GA
                       (was: 1.4.4.GA)


> 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://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.5.GA
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 02:33:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 23 Jun 2009 02:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-213) add JCA DTD files
Message-ID: <2485970.1245738836463.JavaMail.jira@cloud.prod.atl2.jboss.com>

add JCA DTD files
-----------------

                 Key: JBMETA-213
                 URL: https://jira.jboss.org/jira/browse/JBMETA-213
             Project: JBoss Metadata
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.2.Beta2


add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/comon

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 02:44:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 23 Jun 2009 02:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-213) add JCA DTD files
In-Reply-To: <2485970.1245738836463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6765797.1245739496611.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Zhang resolved JBMETA-213.
-------------------------------

    Resolution: Done


> add JCA DTD files
> -----------------
>
>                 Key: JBMETA-213
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-213
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.2.Beta2
>
>
> add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/rar

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 02:44:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 23 Jun 2009 02:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-213) add JCA DTD files
In-Reply-To: <2485970.1245738836463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24013115.1245739496484.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Zhang updated JBMETA-213:
------------------------------

    Description: add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/rar  (was: add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/comon)


> add JCA DTD files
> -----------------
>
>                 Key: JBMETA-213
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-213
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.2.Beta2
>
>
> add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/rar

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 04:13:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 23 Jun 2009 04:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16690090.1245744836925.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf updated EJBTHREE-1852:
------------------------------------

    Fix Version/s: 1.1.8


> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.8
>
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 04:20:34 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 23 Jun 2009 04:20:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20319660.1245745234257.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf resolved EJBTHREE-1852.
-------------------------------------

    Resolution: Done


I've removed the obsolete code from InterceptorInfoRepository which also caused this error.

Note that instantiating an InterceptorInfoRepository will now produce a warning:
09:49:32,195 WARN  [InterceptorInfoRepository] EJBTHREE-1852: InterceptorInfoRepository is deprecated

These should be dealt with once the next release of EJB 3 is integrated. A bean developer can safely ignore the warnings.

> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.8
>
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 04:21:57 2009
From: jira-events at lists.jboss.org (Corneil du Plessis (JIRA))
Date: Tue, 23 Jun 2009 04:21:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2136) Simple match rule
 fails on 5.0.1 and works on 4.0.7
Message-ID: <17964558.1245745317053.JavaMail.jira@cloud.prod.atl2.jboss.com>

Simple match rule fails on 5.0.1 and works on 4.0.7
---------------------------------------------------

                 Key: JBRULES-2136
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2136
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Corneil du Plessis
            Assignee: Mark Proctor


A simple rule that worked in 4.0.7 fails in 5.0.1
An Eclipse project to illustrate the problem will be attached to this issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 04:25:58 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Tue, 23 Jun 2009 04:25:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-421) Configuring
 security with "-jboss-beans.xml" should trim module options
Message-ID: <21788667.1245745558863.JavaMail.jira@cloud.prod.atl2.jboss.com>

Configuring security with "-jboss-beans.xml" should trim module options
-----------------------------------------------------------------------

                 Key: SECURITY-421
                 URL: https://jira.jboss.org/jira/browse/SECURITY-421
             Project: JBoss Security and Identity Management
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Wolfgang Knauf
            Assignee: Anil Saldhana


See the linked forum post: if security is configured through a "...-jboss-beans.xml" file, then the module options are not trimmed. For a DatabaseServerLoginModule, this is fatal for the "dsJndiName" attribute, because even logging the security layer reports a "NameNotFoundException", but the JndiName in the error message seems valid.

E.g. Eclipse might add additional newlines when the xml file is autoformatted.

The old approach with "login-config.xml" seems to do this trimming, so it is even more confusing for users, especially if an old file is migrated (as I did). I would call this an regression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 04:42:08 2009
From: jira-events at lists.jboss.org (Corneil du Plessis (JIRA))
Date: Tue, 23 Jun 2009 04:42:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2136) Simple match rule
 fails on 5.0.1 and works on 4.0.7
In-Reply-To: <17964558.1245745317053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1399428.1245746528084.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Corneil du Plessis updated JBRULES-2136:
----------------------------------------

    Attachment: drools-test.zip


This is an Eclipse project file.
The relevant files required from Drools/lib is not included in this project file.

> Simple match rule fails on 5.0.1 and works on 4.0.7
> ---------------------------------------------------
>
>                 Key: JBRULES-2136
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2136
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Corneil du Plessis
>            Assignee: Mark Proctor
>         Attachments: drools-test.zip
>
>
> A simple rule that worked in 4.0.7 fails in 5.0.1
> An Eclipse project to illustrate the problem will be attached to this issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 05:39:56 2009
From: jira-events at lists.jboss.org (Osamu Yokomizo (JIRA))
Date: Tue, 23 Jun 2009 05:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8012311.1245749996807.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473389#action_12473389 ] 

Osamu Yokomizo commented on EJBTHREE-995:
-----------------------------------------

Hi , Andrew.

It was not generated in AS 5.1.0.
Are not you mended in 4.x ?

1: deploy sample-AS5x.jar
2: execute client SampleClient.
   SampleClient is in sample-AS5x.jar

server.log
====

17:31:44,187 INFO  [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 27s:859ms
17:32:13,796 WARN  [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used
 via the bean container
17:32:13,796 WARN  [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used
 via the bean container
17:32:13,812 INFO  [STDOUT] ut.begin():6
17:32:13,812 INFO  [STDOUT] afterBegin()
17:32:13,828 INFO  [STDOUT] beforeCompletion():
17:32:13,828 INFO  [STDOUT] afterCompletion():true


> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>         Attachments: sample.jar, src.zip
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 05:43:56 2009
From: jira-events at lists.jboss.org (Osamu Yokomizo (JIRA))
Date: Tue, 23 Jun 2009 05:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7102235.1245750236868.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Osamu Yokomizo updated EJBTHREE-995:
------------------------------------

    Attachment: src-AS5x.zip


This is source files for AS5x. 

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>         Attachments: sample-AS5x.jar, sample.jar, src-AS5x.zip, src.zip
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 05:43:57 2009
From: jira-events at lists.jboss.org (Osamu Yokomizo (JIRA))
Date: Tue, 23 Jun 2009 05:43:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3113342.1245750237112.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Osamu Yokomizo updated EJBTHREE-995:
------------------------------------

    Attachment: sample-AS5x.jar


This is jar(EJB and Client)  for AS5x

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>         Attachments: sample-AS5x.jar, sample.jar, src-AS5x.zip, src.zip
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 06:19:57 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Tue, 23 Jun 2009 06:19:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7023) Web Beans
 integration points container task
In-Reply-To: <1066442.1245083216361.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <615257.1245752397241.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Pete Muir updated JBAS-7023:
----------------------------

    Priority: Critical  (was: Major)


> Web Beans integration points container task
> -------------------------------------------
>
>                 Key: JBAS-7023
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7023
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Beans
>            Reporter: Pete Muir
>            Assignee: Pete Muir
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Container task for Web Beans integration tasks to allow JBoss AS to fully pass TCK

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 06:23:56 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 23 Jun 2009 06:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMICROCONT-446) bean-deployer
 xsds don't contain web references
In-Reply-To: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25411578.1245752636535.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Kabir Khan reassigned JBMICROCONT-446:
--------------------------------------

    Assignee: Kabir Khan


> bean-deployer xsds don't contain web references
> -----------------------------------------------
>
>                 Key: JBMICROCONT-446
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Wolfgang Knauf
>            Assignee: Kabir Khan
>
> bean-deployer_2_0.xsd:
>    <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
> =>should point. 
>    <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">
> The comment for a sample instance should also contain a schema location attribute:
>          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xmlns="urn:jboss:bean-deployer:2.0"
>             xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">
> ==================
> bean-deployer_1_0.xsd:
> The comment for a sample instance should point to the web schema location:
>          <deployment
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
>             xmlns="urn:jboss:bean-deployer">
> =================
> policy_1_0.xsd:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
> should be:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>
> =================
> bean-deployer_2_0.xsd raises validation errors in Eclipse:
> -rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
> -src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
> According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 06:27:56 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Tue, 23 Jun 2009 06:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7046) Support CDI
 injection into managed Servlet objects
Message-ID: <24256304.1245752876415.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support CDI injection into managed Servlet objects
--------------------------------------------------

                 Key: JBAS-7046
                 URL: https://jira.jboss.org/jira/browse/JBAS-7046
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Pete Muir
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 07:17:56 2009
From: jira-events at lists.jboss.org (Tobias Meyer (JIRA))
Date: Tue, 23 Jun 2009 07:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-85) IllegalAccessError
 when trying to call clone() on a class generated by ProxyFactory
Message-ID: <15165406.1245755876804.JavaMail.jira@cloud.prod.atl2.jboss.com>

IllegalAccessError when trying to call clone() on a class generated by ProxyFactory
-----------------------------------------------------------------------------------

                 Key: JASSIST-85
                 URL: https://jira.jboss.org/jira/browse/JASSIST-85
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.10.0.GA
            Reporter: Tobias Meyer
            Assignee: Shigeru Chiba


Hibernate 3.3 uses javassist (by default) to generate LazyInitializer Objects.
If a lazily loaded object implements the clone() method, and makes it public, there will be a runtime IllegalAccessError because the javassist proxy object exports the protected definition of Object.clone() instead of the definition in the MethodHandler's Interface.

The supplied patch makes the ProxyFactory to never reduce the visibility of a public method, even if implemented in a higher interface or the superclass.
Normally the java compiler would catch such an error, so this is assumed to be save.

Side effect is of course that a superclass method given to ProxyFactory might not be called as before because a public definition of the MethodHandler (Interface) overloads it.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 08:05:56 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 23 Jun 2009 08:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-740) More workarounds for
 bug in IBM's Class.getDeclaringClass() implementation
Message-ID: <10151921.1245758756509.JavaMail.jira@cloud.prod.atl2.jboss.com>

More workarounds for bug in IBM's Class.getDeclaringClass() implementation
--------------------------------------------------------------------------

                 Key: JBAOP-740
                 URL: https://jira.jboss.org/jira/browse/JBAOP-740
             Project: JBoss AOP
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.2.GA
            Reporter: Kabir Khan
             Fix For: 2.1.3.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 08:05:56 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 23 Jun 2009 08:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-740) More workarounds
 for bug in IBM's Class.getDeclaringClass() implementation
In-Reply-To: <10151921.1245758756509.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1669481.1245758756678.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAOP-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473414#action_12473414 ] 

Kabir Khan commented on JBAOP-740:
----------------------------------

See linked issues for a more detailed description

> More workarounds for bug in IBM's Class.getDeclaringClass() implementation
> --------------------------------------------------------------------------
>
>                 Key: JBAOP-740
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-740
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.2.GA
>            Reporter: Kabir Khan
>             Fix For: 2.1.3.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 07:52:57 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 23 Jun 2009 07:52:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5239199.1245757977288.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Kabir Khan updated JBAS-6888:
-----------------------------

    Attachment: RunIt.java


Having run the standalone AOP tests on the IBM JDK, it seems to be more problems with Class.getDeclaringClass(). I wrote a simple test in RunIt.java, which works as expected both for Class.getDeclaringClass() and Class.getEnclosingClass() on both Sun and IBM JVMs

>From what I can see though, the places where we actually make these calls is on generated classes (i.e. the Advisors), and these methods are native, so maybe it is getting confused somehow because the classes did not exist when the classloader was initialised. I will see if I can fix it.

Does anybody know of a reliable way to determine from java if running in IBMs JDK?

> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Flavia Rainone
>         Attachments: RunIt.java, server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 09:30:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 23 Jun 2009 09:30:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7044)
 "java.io.NotSerializableException: java.util.HashMap$KeySet" error when
 ManagementView.getComponentTypes() is called over a remote connection
In-Reply-To: <23794448.1245682376767.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20891070.1245763857428.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott M Stark resolved JBAS-7044.
---------------------------------

    Resolution: Done


Fixed by ensuring the set returned was serializable

> "java.io.NotSerializableException: java.util.HashMap$KeySet" error when ManagementView.getComponentTypes() is called over a remote connection
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7044
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7044
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Exception in thread "main" org.jboss.remoting.InvocationFailureException: Unable to perform invocation; nested exception is:
>         java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: java.util.HashMap$KeySet
>         at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:142)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:891)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentTypes(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:165)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:118)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:112)
> Caused by: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: java.util.HashMap$KeySet
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentTypes(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:165)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:118)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:112)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         ... 9 more
> Caused by: java.io.NotSerializableException: java.util.HashMap$KeySet
>         at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
>         at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
>         at org.jboss.aop.joinpoint.InvocationResponse.writeExternal(InvocationResponse.java:100)
>         at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1421)
>         at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1390)
>         at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
>         at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
>         at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
>         at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
>         at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
>         at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:120)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:95)
>         at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120)
>         at org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:75)
>         at org.jboss.remoting.transport.socket.ServerThread.versionedWrite(ServerThread.java:1006)
>         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:783)
>         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
>         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:524)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:01:57 2009
From: jira-events at lists.jboss.org (Corneil du Plessis (JIRA))
Date: Tue, 23 Jun 2009 10:01:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2136) Simple match rule
 fails on 5.0.1 and works on 4.0.7
In-Reply-To: <17964558.1245745317053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11077436.1245765717348.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Corneil du Plessis updated JBRULES-2136:
----------------------------------------

    Priority: Critical  (was: Major)


> Simple match rule fails on 5.0.1 and works on 4.0.7
> ---------------------------------------------------
>
>                 Key: JBRULES-2136
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2136
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Corneil du Plessis
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: drools-test.zip
>
>
> A simple rule that worked in 4.0.7 fails in 5.0.1
> An Eclipse project to illustrate the problem will be attached to this issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:21:56 2009
From: jira-events at lists.jboss.org (Jay Balunas (JIRA))
Date: Tue, 23 Jun 2009 10:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-5615) Synchronization
 mutex for clustered environments
In-Reply-To: <31351334.1213134137427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33215073.1245766916855.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jay Balunas reassigned JBAS-5615:
---------------------------------

    Assignee: Scott Marlow


Spoke with Scott Marlow who had some thought on the issue, and will comment.

> Synchronization mutex for clustered environments
> ------------------------------------------------
>
>                 Key: JBAS-5615
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5615
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: Nick Belaevski
>            Assignee: Scott Marlow
>            Priority: Minor
>
> Quote from http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136590 : "they'll need to be thread safe or have access to them synchronized".
> There's no object to synchronize against: SessionBasedClusteredSession doesn synchronization against itself:
>    public void writeExternal(ObjectOutput out) throws IOException
>    {
>       synchronized (this)
>       {
>          ...
>      }   
>    
>    } 
> but application developers see the wrapped one (instance of StandardSessionFacade), so synchronizing against session object does not prevent from concurrency errors

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:25:56 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Tue, 23 Jun 2009 10:25:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7047) Deployers hide
 exception cause stack
Message-ID: <6579847.1245767156834.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deployers hide exception cause stack
------------------------------------

                 Key: JBAS-7047
                 URL: https://jira.jboss.org/jira/browse/JBAS-7047
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Pete Muir




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:25:57 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Tue, 23 Jun 2009 10:25:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7047) Deployers hide
 exception cause stack
In-Reply-To: <6579847.1245767156834.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32302413.1245767157970.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Pete Muir updated JBAS-7047:
----------------------------

    Description: Currently the deployers unwrap all deployment exceptions to the root cause, and store in incompleteDeployments. This means we can't check for exception wrapping


> Deployers hide exception cause stack
> ------------------------------------
>
>                 Key: JBAS-7047
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7047
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Pete Muir
>
> Currently the deployers unwrap all deployment exceptions to the root cause, and store in incompleteDeployments. This means we can't check for exception wrapping

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:29:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 23 Jun 2009 10:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1850) Synchronizations
 registered on the tx depend on ordering
In-Reply-To: <4600779.1245147596442.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7088418.1245767396715.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf updated EJBTHREE-1850:
------------------------------------

      Component/s: core
    Fix Version/s: 1.1.8
                       (was: EAP 5)


> Synchronizations registered on the tx depend on ordering
> --------------------------------------------------------
>
>                 Key: EJBTHREE-1850
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1850
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: 1.1.8
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:31:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 23 Jun 2009 10:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1850)
 Synchronizations registered on the tx depend on ordering
In-Reply-To: <4600779.1245147596442.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27914075.1245767516848.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf resolved EJBTHREE-1850.
-------------------------------------

    Resolution: Done


Synchronizations are now managed within StatefulBeanContext.

> Synchronizations registered on the tx depend on ordering
> --------------------------------------------------------
>
>                 Key: EJBTHREE-1850
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1850
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: 1.1.8
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:32:00 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 23 Jun 2009 10:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-898) Logging stays
 silent when a RuntimeException is thrown from preDestroy method
In-Reply-To: <32474345.1172739140007.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8119608.1245767520077.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf resolved EJBTHREE-898.
------------------------------------

    Resolution: Done
      Assignee: Carlo de Wolf


The code in EJBTHREE-1850 does additional logging when something fails in beforeCompletion or afterCompletion.

> Logging stays silent when a RuntimeException is thrown from preDestroy method
> -----------------------------------------------------------------------------
>
>                 Key: EJBTHREE-898
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-898
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: Branch_4_2
>
>
> 09:48:47,432 INFO  [STDOUT] ContainedBean.preDestroy
> 09:48:47,432 WARN  [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator_4] TwoPhaseCoordinator.afterCompletion - returned failure for com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple at 1ccc3ea

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:32:01 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 23 Jun 2009 10:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-898) Logging stays
 silent when a RuntimeException is thrown from preDestroy method
In-Reply-To: <32474345.1172739140007.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9242749.1245767521033.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf updated EJBTHREE-898:
-----------------------------------

    Fix Version/s: 1.1.8
                       (was: Branch_4_2)


> Logging stays silent when a RuntimeException is thrown from preDestroy method
> -----------------------------------------------------------------------------
>
>                 Key: EJBTHREE-898
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-898
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: 1.1.8
>
>
> 09:48:47,432 INFO  [STDOUT] ContainedBean.preDestroy
> 09:48:47,432 WARN  [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator_4] TwoPhaseCoordinator.afterCompletion - returned failure for com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple at 1ccc3ea

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:35:58 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 23 Jun 2009 10:35:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1854) Configure EJB3
 MC beans to avoid AOPDependencyBuilder
Message-ID: <16175879.1245767758566.JavaMail.jira@cloud.prod.atl2.jboss.com>

Configure EJB3 MC beans to avoid AOPDependencyBuilder
-----------------------------------------------------

                 Key: EJBTHREE-1854
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1854
             Project: EJB 3.0
          Issue Type: Task
          Components: core, deployers
    Affects Versions: 1.1.7
            Reporter: jaikiran pai
            Assignee: jaikiran pai


This task is to keep track of the change(s) required for all EJB3 MC bean (programatic and xml based) to ensure that the AOPDependencyBuilder does not come into picture during deployment. Avoiding AOPDependencyBuilder has shown good performance improvements.

There isn't a final decision yet on how to do this although MC provides @DisableAOP annotation to achieve this. The MC support for this is currently available in AS 5_x branch and needs to be ported to AS trunk before EJB3 can think of using this. Once there's a decision on what's the best approach to accomplish this, we can do the changes in EJB3.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 11:16:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 23 Jun 2009 11:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1437) Browsers
 should iterate on queue
In-Reply-To: <33355941.1225819521109.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15335449.1245770216703.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil updated JBMESSAGING-1437:
-------------------------------------

    Attachment: patch-JBMESSAGING-1437.txt


strike 2!

this patch is more correct wrt to promptDelivery and credit flow control.

however, it still does not work with large messages at the moment.

> Browsers should iterate on queue
> --------------------------------
>
>                 Key: JBMESSAGING-1437
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1437
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>         Attachments: patch-JBMESSAGING-1437.txt
>
>
> Currently the server browser implementation is taking a snapshot of the queue and browsing that. Instead we should implement an iterator on the queue which allows refs to be added or removed from the ends without affecting it.
> This is also necessary to allow failover for browsers which is very hard to implement with the current snapshot approach

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 11:16:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 23 Jun 2009 11:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1437) Browsers
 should iterate on queue
In-Reply-To: <33355941.1225819521109.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26733170.1245770216915.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil updated JBMESSAGING-1437:
-------------------------------------

    Attachment:     (was: patch-JBMESSAGING-1437.txt)


> Browsers should iterate on queue
> --------------------------------
>
>                 Key: JBMESSAGING-1437
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1437
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>         Attachments: patch-JBMESSAGING-1437.txt
>
>
> Currently the server browser implementation is taking a snapshot of the queue and browsing that. Instead we should implement an iterator on the queue which allows refs to be added or removed from the ends without affecting it.
> This is also necessary to allow failover for browsers which is very hard to implement with the current snapshot approach

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 11:42:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jun 2009 11:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7048) Switch HAPartition to
 LongRunningTasksThreadPool
Message-ID: <20000345.1245771776621.JavaMail.jira@cloud.prod.atl2.jboss.com>

Switch HAPartition to LongRunningTasksThreadPool
------------------------------------------------

                 Key: JBAS-7048
                 URL: https://jira.jboss.org/jira/browse/JBAS-7048
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-6.0.0.Alpha1


Now uses "ThreadPool" but for a long running task.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 11:44:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 23 Jun 2009 11:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1851) Investigate
 the failure
 org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
In-Reply-To: <10648726.1245161216783.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <812217.1245771896796.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473465#action_12473465 ] 

jaikiran pai commented on EJBTHREE-1851:
----------------------------------------

This testcase deploys multiple deployments and some deployments have the same bean names. The EJB3MetricsDeployer currently deploys MC beans based on the EJB names:

2009-06-23 21:00:30,589 DEBUG [org.jboss.ejb3.metrics.deployer.Ejb3MetricsDeployer] (RMI TCP Connection(10)-127.0.0.1) Attaching MC Bean with name "StatelessBean" ....

This can lead to duplicate binding exceptions if there are multiple deployments containing the same EJB names:

2009-06-23 21:00:39,736 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (RMI TCP Connection(10)-127.0.0.1) Error installing to Real: name=vfszip:/path/target/test-lib/stateful-test.jar/ state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying: StatelessBean
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:125)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java: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:1632)
	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.deployment.MainDeployer.deploy(MainDeployer.java:831)
	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:605)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.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 sun.reflect.GeneratedMethodAccessor333.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
	at sun.reflect.GeneratedMethodAccessor323.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
	at sun.reflect.GeneratedMethodAccessor322.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
	at sun.reflect.GeneratedMethodAccessor321.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
	at sun.rmi.transport.Transport$1.run(Transport.java:153)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
	at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalStateException: StatelessBean is already installed.
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
	... 65 more


The EJB3MetricsDeployer could be changed to deploy MC beans with names that include even the deployment name, which contains the EJB.

> Investigate the failure org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
> -------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1851
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1851
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: testsuite
>    Affects Versions: 1.1.7
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> The org.jboss.ejb3.test.container.unit.ContainerTestCase consistently fails with:
> javax.naming.NameNotFoundException: Stateful not bound
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
> 	at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
> 	at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> 	at java.lang.Thread.run(Thread.java:595)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> 	at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at org.jboss.ejb3.test.container.unit.ContainerTestCase.testInvocationStatistics(ContainerTestCase.java:93)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
> 	at junit.extensions.TestSetup.run(TestSetup.java:27)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 13:30:09 2009
From: jira-events at lists.jboss.org (Sachin Chandradethan (JIRA))
Date: Tue, 23 Jun 2009 13:30:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1665) Unable to
 create durable queues using adminstered object(JMX)
Message-ID: <13778345.1245778209824.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unable to create durable queues using adminstered object(JMX)
-------------------------------------------------------------

                 Key: JBMESSAGING-1665
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1665
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 2.0.0.beta3
         Environment: OS: Windows Vista. JDK 1.6
            Reporter: Sachin Chandradethan
            Assignee: Tim Fox


 I tried to create queues in dynamically using JMX Administered Objects.  I could create the queues successfully. But once  messaging server is shutdown, the queues are disappeared. I tried to create the queues using JConsole also. Same thing is happening there also. The queues were disappeared once the server is restarted.

 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 13:49:57 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jun 2009 13:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7015) AS JChannelFactory
 should always add singleton_name
In-Reply-To: <10577550.1244837396926.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21290288.1245779397154.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry updated JBAS-7015:
-----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                       (was: JBossAS-6.0.0.Alpha1)


> AS JChannelFactory should always add singleton_name
> ---------------------------------------------------
>
>                 Key: JBAS-7015
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7015
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Currently it only adds a singleton_name if channel is requested via createMultiplexerChannel() methods, not for createChannel(String stack). But the latter will possibly become the default, and if two services request channels from the same stack and there is no singleton_name, there will be conflicts. The AS should use a shared transport whenever possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 13:49:57 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jun 2009 13:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7009) AS JChannelFactory
 shouldn't subclass the JGroups version
In-Reply-To: <14168838.1244666337520.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15690516.1245779397316.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry updated JBAS-7009:
-----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                       (was: JBossAS-6.0.0.Alpha1)


> AS JChannelFactory shouldn't subclass the JGroups version
> ---------------------------------------------------------
>
>                 Key: JBAS-7009
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7009
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The AS JChannelFactory class started off as a subclass of the JGroups version with a few small differences. Over time it has added a lot of specialized behavior, and exposing a full-featured ManagedObject interface requires adding significantly more. At this point the benefits of subclassing don't justify the hassle of keeping them coupled.
> Both implement the ChannelFactory interface, which is the client view.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 13:55:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jun 2009 13:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7009) AS JChannelFactory
 shouldn't subclass the JGroups version
In-Reply-To: <14168838.1244666337520.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15744117.1245779756962.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry closed JBAS-7009.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> AS JChannelFactory shouldn't subclass the JGroups version
> ---------------------------------------------------------
>
>                 Key: JBAS-7009
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7009
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The AS JChannelFactory class started off as a subclass of the JGroups version with a few small differences. Over time it has added a lot of specialized behavior, and exposing a full-featured ManagedObject interface requires adding significantly more. At this point the benefits of subclassing don't justify the hassle of keeping them coupled.
> Both implement the ChannelFactory interface, which is the client view.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 13:57:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jun 2009 13:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7014) JChannelFactory
 addSingletonName handling broken
In-Reply-To: <26543394.1244836196419.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31583178.1245779876559.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry closed JBAS-7014.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> JChannelFactory addSingletonName handling broken
> ------------------------------------------------
>
>                 Key: JBAS-7014
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7014
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-5.1.0.CR1, JBossAS-5.1.0.GA
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The expected path for the AS JChannelFactory's addSingletonName logic is broken -- it thinks it is mutating the passed in config but it isn't.
> Luckily this is minor because there's separate logic that executes when JGroups throws an UnsupportedOperationException -- said logic works correctly and JGroups always throws the exception. But if a later release of JGroups fixed the UOE, this bug would be exposed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 13:57:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jun 2009 13:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7015) AS JChannelFactory
 should always add singleton_name
In-Reply-To: <10577550.1244837396926.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24464724.1245779876697.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry closed JBAS-7015.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> AS JChannelFactory should always add singleton_name
> ---------------------------------------------------
>
>                 Key: JBAS-7015
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7015
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Currently it only adds a singleton_name if channel is requested via createMultiplexerChannel() methods, not for createChannel(String stack). But the latter will possibly become the default, and if two services request channels from the same stack and there is no singleton_name, there will be conflicts. The AS should use a shared transport whenever possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 13:57:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jun 2009 13:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7016) Management interface
 for JChannelFactory
In-Reply-To: <9111063.1244840876545.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30947091.1245779876827.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Stansberry closed JBAS-7016.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> Management interface for JChannelFactory
> ----------------------------------------
>
>                 Key: JBAS-7016
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7016
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 14:15:57 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 23 Jun 2009 14:15:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7035) Help avoid unneeded
 scanning of classes for annotations by adding jboss-scanning.xml
In-Reply-To: <32851153.1245270596605.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33111965.1245780957695.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Scott Marlow updated JBAS-7035:
-------------------------------

    Description: 
Please add the attached jboss-scanning.xml file to folders:
  jbossws.sar/jbossws-management.war/META-INF
  jbossws.sar/jbossws-management.war/WEB-INF
  juddi-service.sar/META-INF
  juddi.war/WEB-INF

  was:
Please add the attached jboss-scanning.xml file to folders:
  jbossws.sar/jbossws-management.war/META-INF
  jbossws.sar/jbossws-management.war/WEB-INF




> Help avoid unneeded scanning of classes for annotations by adding jboss-scanning.xml
> ------------------------------------------------------------------------------------
>
>                 Key: JBAS-7035
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7035
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott Marlow
>            Assignee: Alessio Soldano
>             Fix For: JBossAS-6.0.0.Alpha1
>
>         Attachments: jboss-scanning.xml
>
>
> Please add the attached jboss-scanning.xml file to folders:
>   jbossws.sar/jbossws-management.war/META-INF
>   jbossws.sar/jbossws-management.war/WEB-INF
>   juddi-service.sar/META-INF
>   juddi.war/WEB-INF

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 14:26:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 23 Jun 2009 14:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
Message-ID: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>

tests-jacc-securitymgr test server fails to start with OpenJDK 6
----------------------------------------------------------------

                 Key: JBAS-7049
                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
            Reporter: Shelly McGowan
            Assignee: Anil Saldhana
             Fix For: JBossAS-5.2.0.Beta1


This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 14:26:56 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Tue, 23 Jun 2009 14:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-7050) Unable to create any
 kind of datasource or connection factory
Message-ID: <32284770.1245781616843.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Charles Crouch moved JOPR-236 to JBAS-7050:
-------------------------------------------

              Project: JBoss Application Server  (was: Jopr)
                  Key: JBAS-7050  (was: JOPR-236)
          Component/s:     (was: Plugin - JBoss AS 5)
        Fix Version/s: JBossAS-5.2.0.Beta1
                           (was: 2.3)
    Affects Version/s: JBossAS-5.1.0.GA
                           (was: 2.3)
             Security: Public


> Unable to create any kind of datasource or connection factory
> -------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 14:30:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 23 Jun 2009 14:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22496903.1245781856503.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-7049:
---------------------------------

    Attachment: boot.log
                error.log
                output.log


Logs attached.
CI test runs can be seen here:
http://hudson.qa.jboss.com/hudson/view/JBoss AS/job/JBoss-AS-5.1.x-testSuite-openjdk6

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 14:48:56 2009
From: jira-events at lists.jboss.org (Jay Balunas (JIRA))
Date: Tue, 23 Jun 2009 14:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-5615) Synchronization
 mutex for clustered environments
In-Reply-To: <31351334.1213134137427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28442019.1245782936606.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jay Balunas commented on JBAS-5615:
-----------------------------------

Scott added comments to the forum post listed above for more information.  Not sure if Nick is monitoring, so a comment here should email Nick on it.

> Synchronization mutex for clustered environments
> ------------------------------------------------
>
>                 Key: JBAS-5615
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5615
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: Nick Belaevski
>            Assignee: Scott Marlow
>            Priority: Minor
>
> Quote from http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136590 : "they'll need to be thread safe or have access to them synchronized".
> There's no object to synchronize against: SessionBasedClusteredSession doesn synchronization against itself:
>    public void writeExternal(ObjectOutput out) throws IOException
>    {
>       synchronized (this)
>       {
>          ...
>      }   
>    
>    } 
> but application developers see the wrapped one (instance of StandardSessionFacade), so synchronizing against session object does not prevent from concurrency errors

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 15:26:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 23 Jun 2009 15:26:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1665) Unable to
 create durable queues using adminstered object(JMX)
In-Reply-To: <13778345.1245778209824.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4445476.1245785217008.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Tim Fox commented on JBMESSAGING-1665:
--------------------------------------

Sachin-

I think you'll find the JMS queues have not disappeared - try producer/consuming from them.

The queues will still exist even though they are not in JNDI/registered in management.

Only JMS queues that are explicitly declared in jbm-jms.xml will be loaded into JNDI/management on startup

> Unable to create durable queues using adminstered object(JMX)
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1665
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1665
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 2.0.0.beta3
>         Environment: OS: Windows Vista. JDK 1.6
>            Reporter: Sachin Chandradethan
>            Assignee: Tim Fox
>
>  I tried to create queues in dynamically using JMX Administered Objects.  I could create the queues successfully. But once  messaging server is shutdown, the queues are disappeared. I tried to create the queues using JConsole also. Same thing is happening there also. The queues were disappeared once the server is restarted.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 16:04:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Tue, 23 Jun 2009 16:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
Message-ID: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>

ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
--------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7051
                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Scott M Stark
             Fix For: JBossAS-5.2.0.Beta1


This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:

1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.

2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:

container=JBossMQ|JBossMessaging

which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.


Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:

15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
rvice=Queue, parent=JBoss EAP 5 (default)]
org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
        at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
        at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
rceManager.java:235)
        at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
figurationUIBean.java:144)
        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.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
        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.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.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
tion(ResourceConfigurationUIBean_$$_javassist_12.java)
        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.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
        at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
        at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
        at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
        at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
        at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
        at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
        at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
        at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
        at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
        at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
        at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
        at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
        at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
        at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
        at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
        at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
        at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
        at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
        at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
        at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        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:235)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
a:126)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
:70)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
        ... 84 more


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 16:12:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 23 Jun 2009 16:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2133) Drools-solver
 manual corrections from Yet another math programming consultant blog
In-Reply-To: <15744621.1245657057041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6922321.1245787976933.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Geoffrey De Smet commented on JBRULES-2133:
-------------------------------------------

fixed in subversion

> Drools-solver manual corrections from Yet another math programming consultant blog
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2133
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2133
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Optional
>             Fix For: 5.1.0.M1
>
>
> http://yetanothermathprogrammingconsultant.blogspot.com/2009/06/simplex-method-description.html?showComment=1245656649020#c9186233704679009828
> - The branch&bound section should mention about the unique feature that it provides bounds and hence an indication of the quality of the solution.
> - The simplex  section is supposedly wrong (It's unclear how it can be corrected): "If the word Simplex was missing I would not recognize this is about the Simplex method. One big equation? (No word about not being suited to handle discrete variables)."
> - "Local search starts from an initial solution and evolves that single solution into a better and better solution." should be "Local search starts from an initial solution and evolves that single solution, ussually into a better and better solution."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 16:12:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 23 Jun 2009 16:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2133) Drools-solver
 manual corrections from Yet another math programming consultant blog
In-Reply-To: <15744621.1245657057041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24224762.1245787976792.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Geoffrey De Smet resolved JBRULES-2133.
---------------------------------------

    Fix Version/s: 5.1.0.M1
       Resolution: Done


> Drools-solver manual corrections from Yet another math programming consultant blog
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2133
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2133
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Optional
>             Fix For: 5.1.0.M1
>
>
> http://yetanothermathprogrammingconsultant.blogspot.com/2009/06/simplex-method-description.html?showComment=1245656649020#c9186233704679009828
> - The branch&bound section should mention about the unique feature that it provides bounds and hence an indication of the quality of the solution.
> - The simplex  section is supposedly wrong (It's unclear how it can be corrected): "If the word Simplex was missing I would not recognize this is about the Simplex method. One big equation? (No word about not being suited to handle discrete variables)."
> - "Local search starts from an initial solution and evolves that single solution into a better and better solution." should be "Local search starts from an initial solution and evolves that single solution, ussually into a better and better solution."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 16:12:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Tue, 23 Jun 2009 16:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <669170.1245787976661.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-7051:
-------------------------------

    Attachment: jboss-ejb3-tutorial-mdb.jar


The attached EJB-JAR contains a couple JBossMQ queues that can be used to demonstrate this issue. Deploy it to an EAP5 instance and then in the Admin Console go to the Configuration tabs of one of the below Queue Resources:

jboss.mq.destination:name=tutorial,service=Queue 
jboss.mq.destination:name=defaultedtutorial,service=Queue 

You'll see the 'serverPeer' CCE in the server log.


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         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.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         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.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.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         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.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 16:39:56 2009
From: jira-events at lists.jboss.org (Nick Belaevski (JIRA))
Date: Tue, 23 Jun 2009 16:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-5615) Synchronization
 mutex for clustered environments
In-Reply-To: <31351334.1213134137427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13796112.1245789596576.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Nick Belaevski commented on JBAS-5615:
--------------------------------------

Thanks, Jay! 

I've posted information I have on forum.

> Synchronization mutex for clustered environments
> ------------------------------------------------
>
>                 Key: JBAS-5615
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5615
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: Nick Belaevski
>            Assignee: Scott Marlow
>            Priority: Minor
>
> Quote from http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136590 : "they'll need to be thread safe or have access to them synchronized".
> There's no object to synchronize against: SessionBasedClusteredSession doesn synchronization against itself:
>    public void writeExternal(ObjectOutput out) throws IOException
>    {
>       synchronized (this)
>       {
>          ...
>      }   
>    
>    } 
> but application developers see the wrapped one (instance of StandardSessionFacade), so synchronizing against session object does not prevent from concurrency errors

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 17:18:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Tue, 23 Jun 2009 17:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7052) when invoked from
 remote client, 
 call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
Message-ID: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>

when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7052
                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Scott M Stark
            Priority: Critical
             Fix For: JBossAS-5.2.0.Beta1


The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.

To reproduce this, the following client code can be used:
https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/

Just do:
mvn install
cd target
java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar

Here's the stack trace:

Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
        at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
        at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
        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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.HashSet.readObject(HashSet.java:291)
        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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.HashSet.readObject(HashSet.java:291)
        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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
        at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
        at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
        at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 17:54:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 23 Jun 2009 17:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2137) Expose
 insertLogical() method into the RuleContext interface
Message-ID: <31462917.1245794096471.JavaMail.jira@cloud.prod.atl2.jboss.com>

Expose insertLogical() method into the RuleContext interface
------------------------------------------------------------

                 Key: JBRULES-2137
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2137
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


Expose insertLogical() method into the RuleContext interface

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 17:58:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 23 Jun 2009 17:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2137) Expose
 insertLogical() method into the RuleContext interface
In-Reply-To: <31462917.1245794096471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14753642.1245794336423.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli closed JBRULES-2137.
----------------------------------

    Resolution: Done


> Expose insertLogical() method into the RuleContext interface
> ------------------------------------------------------------
>
>                 Key: JBRULES-2137
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2137
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> Expose insertLogical() method into the RuleContext interface

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 18:31:56 2009
From: jira-events at lists.jboss.org (Michal Bali (JIRA))
Date: Tue, 23 Jun 2009 18:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2138) RuleContext and
 insertLogical()
Message-ID: <13473430.1245796316751.JavaMail.jira@cloud.prod.atl2.jboss.com>

RuleContext and insertLogical()
-------------------------------

                 Key: JBRULES-2138
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2138
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-api
    Affects Versions: 5.0.1.FINAL
            Reporter: Michal Bali
            Assignee: Mark Proctor
             Fix For: 5.1.0.M1


The org.drools.runtime.rule.RuleContext doesn't support insertLogical() as did the deprecated KnowledgeHelper. Please add this method to RuleContext.

Thank you.
Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 18:31:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Tue, 23 Jun 2009 18:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7052) when invoked from
 remote client, 
 call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2315860.1245796316594.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-7052:
-------------------------------

    Priority: Blocker  (was: Critical)


Raising to Blocker, since this is causing a bunch of stuff to break when running the jbas5 plugin within the Enterprise Jopr Agent.


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 18:35:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Tue, 23 Jun 2009 18:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7314930.1245796556625.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer commented on JBAS-7052:
------------------------------------

I also see a CNFE for ManagedComponentDelegate, another profileservice impl class, which also occurs on calls to getComponentsForType(). Here's the stack trace from the Jopr jbas5 plugin:

2009-06-23 18:26:08,298 ERROR [ResourceContainer.invoker.daemon-11] (org.rhq.plugins.jbossas5.ApplicationServerComponent)- Failed to obtain metric 'MCBean|JTA|*|commitCount'.
java.lang.IllegalStateException: java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedComponentDelegate
	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:165)
	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:67)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:250)
	at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedComponentDelegate
	at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
	at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
	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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
	at java.util.HashSet.readObject(HashSet.java:291)
	at sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:161)
	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:67)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:250)
	at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)
	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:161)
	... 11 more


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 18:55:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 23 Jun 2009 18:55:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2138) RuleContext and
 insertLogical()
In-Reply-To: <13473430.1245796316751.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21531529.1245797757076.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli reassigned JBRULES-2138:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> RuleContext and insertLogical()
> -------------------------------
>
>                 Key: JBRULES-2138
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2138
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-api
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Michal Bali
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> The org.drools.runtime.rule.RuleContext doesn't support insertLogical() as did the deprecated KnowledgeHelper. Please add this method to RuleContext.
> Thank you.
> Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 18:55:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 23 Jun 2009 18:55:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2138) RuleContext and
	insertLogical()
In-Reply-To: <13473430.1245796316751.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4095130.1245797757247.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Edson Tirelli closed JBRULES-2138.
----------------------------------

    Resolution: Done


> RuleContext and insertLogical()
> -------------------------------
>
>                 Key: JBRULES-2138
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2138
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-api
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Michal Bali
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> The org.drools.runtime.rule.RuleContext doesn't support insertLogical() as did the deprecated KnowledgeHelper. Please add this method to RuleContext.
> Thank you.
> Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 22:40:09 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 23 Jun 2009 22:40:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6889) tests in
 tests-aop-scoped failing with IBM JDK
In-Reply-To: <7099808.1242045886541.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26956651.1245811209744.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-6889:
---------------------------------


Correction to above comment:  results after upgrading to JBoss AOP 2.1.2.GA in my local workspace.

> tests in tests-aop-scoped failing with IBM JDK
> ----------------------------------------------
>
>                 Key: JBAS-6889
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6889
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: TEST-org.jboss.test.aop.test.ScopedAnnotatedTestCase-aop-scoped.xml
>
>
> Tests in the tests-aop-scoped target of JBoss AS testsuite are failing.
> The tests are:
> org.jboss.test.aop.test.ScopedAnnotatedTestCase
> org.jboss.test.aop.test.ScopedAttachUnitTestCase
> org.jboss.test.aop.test.ScopedEarWithClassesInWebInfTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseLoadedScopedNoParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseLoadedScopedParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseNotLoadedScopedNoParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseNotLoadedScopedParentDelegationTestCase
> org.jboss.test.aop.test.ScopedUnitTestCase
> org.jboss.test.aop.test.ScopedWovenDependencyTestCase
> The error message is:
> javax.management.RuntimeErrorException
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:182)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: java.lang.ExceptionInInitializerError
> 	at java.lang.J9VMInternals.initialize(J9VMInternals.java:216)
> 	at org.jboss.test.aop.jdk15annotated.ScopedAnnotatedTester.testBinding(ScopedAnnotatedTester.java:50)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.aop.Domain$1.run(Domain.java:124)
> 	at org.jboss.aop.Domain$1.run(Domain.java:121)
> 	at java.security.AccessController.doPrivileged(AccessController.java:197)
> 	at org.jboss.aop.Domain.getDomainName(Domain.java:119)
> 	at org.jboss.test.aop.jdk15annotated.POJO$POJOAdvisor.initialise(POJO$POJOAdvisor.java)
> 	at org.jboss.test.aop.jdk15annotated.POJO$POJOAdvisor.<init>(POJO$POJOAdvisor.java)
> 	at org.jboss.test.aop.jdk15annotated.POJO.<clinit>(POJO.java)
> 	at java.lang.J9VMInternals.initializeImpl(Native Method)
> 	at java.lang.J9VMInternals.initialize(J9VMInternals.java:194)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 22:51:14 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 23 Jun 2009 22:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-214) fix matadata common
	build
Message-ID: <26514201.1245811874997.JavaMail.jira@cloud.prod.atl2.jboss.com>

fix matadata common build
-------------------------

                 Key: JBMETA-214
                 URL: https://jira.jboss.org/jira/browse/JBMETA-214
             Project: JBoss Metadata
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.2.Beta2


compile matadata/common in JDK5 will be failed

[INFO] [compiler:compile]
[INFO] Compiling 182 source files to /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/target/classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure

/home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[29,20] package javax.xml.ws does not exist

/home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/WebServiceHandlerChainProcessor.java:[34,17] package javax.jws does not exist

/home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[70,69] cannot find symbol
symbol  : class WebServiceRef
location: class org.jboss.metadata.annotation.creator.ws.AbstractWebServiceRefProcessor<E>

/home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[99,55] cannot find symbol
symbol  : class WebServiceRef
location: class org.jboss.metadata.annotation.creator.ws.AbstractWebServiceRefProcessor<E>

.....


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 23:04:56 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Tue, 23 Jun 2009 23:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <8305115.1245812696549.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

John Ament commented on JBAS-7032:
----------------------------------

I'm able to reproduce in a number of environments.

Personal PC (work).  Dell optiplex gx745. 2gb ram.
IBM x 336 in clustered mode
Personal laptop, dell studio 1537

work pc is opensuse 11.1 + 64 bit.  2gb ram.
laptop's windows 7 + 64bit. 4gb ram.
336's are 64 bit, jdk 6.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 23:08:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 23 Jun 2009 23:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-214) fix matadata
	common build
In-Reply-To: <26514201.1245811874997.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1677496.1245812936452.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Zhang resolved JBMETA-214.
-------------------------------

    Resolution: Done


> fix matadata common build
> -------------------------
>
>                 Key: JBMETA-214
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-214
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.2.Beta2
>
>
> compile matadata/common in JDK5 will be failed
> [INFO] [compiler:compile]
> [INFO] Compiling 182 source files to /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/target/classes
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Compilation failure
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[29,20] package javax.xml.ws does not exist
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/WebServiceHandlerChainProcessor.java:[34,17] package javax.jws does not exist
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[70,69] cannot find symbol
> symbol  : class WebServiceRef
> location: class org.jboss.metadata.annotation.creator.ws.AbstractWebServiceRefProcessor<E>
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[99,55] cannot find symbol
> symbol  : class WebServiceRef
> location: class org.jboss.metadata.annotation.creator.ws.AbstractWebServiceRefProcessor<E>
> .....

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 00:16:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 24 Jun 2009 00:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <25153643.1245817016723.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-7032:
---------------------------------


And your JBoss AS installation was from the distributed jboss-5.1.0.GA-jdk6.zip?

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 00:19:08 2009
From: jira-events at lists.jboss.org (Sachin Chandradethan (JIRA))
Date: Wed, 24 Jun 2009 00:19:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1665) Unable to
 create durable queues using adminstered object(JMX)
In-Reply-To: <13778345.1245778209824.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18112747.1245817148685.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Sachin Chandradethan closed JBMESSAGING-1665.
---------------------------------------------

    Resolution: Done


Thanks Tim. Its working fine.

> Unable to create durable queues using adminstered object(JMX)
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1665
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1665
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 2.0.0.beta3
>         Environment: OS: Windows Vista. JDK 1.6
>            Reporter: Sachin Chandradethan
>            Assignee: Tim Fox
>
>  I tried to create queues in dynamically using JMX Administered Objects.  I could create the queues successfully. But once  messaging server is shutdown, the queues are disappeared. I tried to create the queues using JConsole also. Same thing is happening there also. The queues were disappeared once the server is restarted.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 02:38:57 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Wed, 24 Jun 2009 02:38:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1666) Add
 "messageCount" attribute on Address MBean
Message-ID: <18851986.1245825537257.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add "messageCount" attribute on Address MBean
---------------------------------------------

                 Key: JBMESSAGING-1666
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1666
             Project: JBoss Messaging
          Issue Type: Feature Request
            Reporter: Bijith Kumar
            Assignee: Tim Fox


Value shown in "messageCount" attribute of a queue MBean does not include the number of messages that are paged. This is because messages are paged to disk  before they are routed in the postoffice. So, for the user to be able to find the total number of messages that are added to a queue, Tim suggested that, we add a "messageCount" attribute to the Address MBean. That would indicate how many messages are paged for a particular destination address.  Please refer http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157325 for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 03:33:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 24 Jun 2009 03:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1855) Switch to
 ejb3-core 1.1.8-SNAPSHOT
Message-ID: <27800202.1245828836468.JavaMail.jira@cloud.prod.atl2.jboss.com>

Switch to ejb3-core 1.1.8-SNAPSHOT
----------------------------------

                 Key: EJBTHREE-1855
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1855
             Project: EJB 3.0
          Issue Type: Task
          Components: as-int, ejb3
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf
             Fix For: 1.1.8




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 03:35:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 24 Jun 2009 03:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1855) Switch to
 ejb3-core 1.1.8-SNAPSHOT
In-Reply-To: <27800202.1245828836468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31576970.1245828956442.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Carlo de Wolf resolved EJBTHREE-1855.
-------------------------------------

    Resolution: Done


> Switch to ejb3-core 1.1.8-SNAPSHOT
> ----------------------------------
>
>                 Key: EJBTHREE-1855
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1855
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: as-int, ejb3
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.8
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 05:24:56 2009
From: jira-events at lists.jboss.org (Toni Rikkola (JIRA))
Date: Wed, 24 Jun 2009 05:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1365) [M]Importing a drl
 with no package statement fails
In-Reply-To: <11983213.1196989342536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1796880.1245835496819.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Toni Rikkola closed JBRULES-1365.
---------------------------------

    Resolution: Done


If there is no name for the package Guvnor now asks for one.

> [M]Importing a drl with no package statement fails
> --------------------------------------------------
>
>                 Key: JBRULES-1365
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1365
>             Project: JBoss Drools
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 4.0.3
>            Reporter: Michael Neale
>            Assignee: Toni Rikkola
>             Fix For: 5.1.0.M1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 05:30:56 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Wed, 24 Jun 2009 05:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-20) JDK loggign
 isLoggable(Level.FINEST) returns false with Log4J backend
Message-ID: <12251162.1245835856606.JavaMail.jira@cloud.prod.atl2.jboss.com>

JDK loggign isLoggable(Level.FINEST) returns false with Log4J backend
---------------------------------------------------------------------

                 Key: JBLOGGING-20
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-20
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-logbridge
         Environment: JBoss 5.1.0, JDK 1.6u13
            Reporter: Ondrej Medek
            Assignee: Dimitris Andreadis


I have code using JDK logging like:

if (LOG.isLoggable(Level.FINEST)) {
  LOG.finest("added into list: " + something);
}

I have no log. When I use just

LOG.finest("added into list: " + something);

I got a log in the log file.

I use JBoss with Log4J. It is configured to log ALL stuff.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 06:26:56 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Wed, 24 Jun 2009 06:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <2453923.1245839216539.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

John Ament commented on JBAS-7032:
----------------------------------

Yes sorry, all are 5.1 JDK6 GA.  Also, it appears to work correctly in 5.1 CR1.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 08:41:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 24 Jun 2009 08:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30254153.1245847316548.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473596#action_12473596 ] 

Alexey Loubyansky commented on JBXB-206:
----------------------------------------

So, the most time consuming is org.jboss.xb.binding.Util#loadSchema(java.io.InputStream, String, org.jboss.xb.binding.sunday.unmarshalling.SchemaBindingResolver). I wonder why it is called at all. It's supposed to be called only from XsdBinder. Which shouldn't be used in your case. We need to debug and see what's triggering that.

> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>         Attachments: jboss-profiler.properties, jbossxb.zip, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 08:46:57 2009
From: jira-events at lists.jboss.org (Naresh Bhatia (JIRA))
Date: Wed, 24 Jun 2009 08:46:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBVFS-109) Trying to access
 all classpath
 resources from a web application fails due to VFS errors
In-Reply-To: <14030842.1241499346657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3071915.1245847617081.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBVFS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473597#action_12473597 ] 

Naresh Bhatia commented on JBVFS-109:
-------------------------------------

Did this fix get into JBoss 5.1.0.GA? I am using JBoss 5.1.0.GA with a Spring application that uses classpath scanning (using <context:component-scan>) fails with the following error:

[org.springframework.core.io.support.PathMatchingResourcePatternResolver]
Cannot search for matching files underneath URL
[vfszip:/D:/jboss-5.1.0/server/default-with-jbm2/deploy/myapp.war/WEB-INF/lib/mylistener-1.0-SNAPSHOT.jar/myapp/mylistener/]
because it does not correspond to a directory in the file system

> Trying to access all classpath resources from a web application fails due to VFS errors
> ---------------------------------------------------------------------------------------
>
>                 Key: JBVFS-109
>                 URL: https://jira.jboss.org/jira/browse/JBVFS-109
>             Project: JBoss VFS
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>            Reporter: Marius Bogoevici
>            Assignee: Ales Justin
>             Fix For: 2.1.2.GA
>
>         Attachments: spring-jboss-jaxws.tar.gz
>
>
> The error has been triggered by using classpath scanning in Spring, but can be reproduced independently.
> The code in the servlet listed below does virtually the same thing as the VFSResourcePatternResolver:
> public class BasicServlet extends HttpServlet{
>     @Override
>     protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
>         ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
>         Enumeration<URL> urls = classLoader.getResources("");
>         StringBuffer buffer = new StringBuffer();
>         while (urls.hasMoreElements()) {
>             URL url = urls.nextElement();
>             VirtualFile file = VFS.getRoot(url);
>             buffer.append(file.getPathName() + "\n");
>         }
>         new PrintWriter(resp.getOutputStream()).println(buffer.toString());
>     }
> }
> Trying to access the servlet results in an error when one URL is converted to a VirtualFile by VFS.getRoot(), and here is the resulting exception. The URL that triggers the error differs if the test is repeated.
> 00:45:44,380 ERROR [[resource-servlet]] Servlet.service() for servlet resource-servlet threw exception
> java.io.IOException: Child not found opt/jboss/jboss-5.0.1.GA/server/default/deployers/jbossws.deployer/policy.jar/ for MemoryContextHandler at 555514482[path= context=vfsmemory://3j011-j4xs2m-fuc3y7a8-1-fuc3yl41-9 real=vfsmemory://3j011-j4xs2m-fuc3y7a8-1-fuc3yl41-9], available children: []
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.findHandler(DefaultVFSRegistry.java:109)
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:88)
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:121)
> 	at org.jboss.virtual.VFS.getRoot(VFS.java:276)
> 	at BasicServlet.doGet(BasicServlet.java:22)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 08:50:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 24 Jun 2009 08:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1437) Browsers
 should iterate on queue
In-Reply-To: <33355941.1225819521109.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12428626.1245847856501.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jeff Mesnil closed JBMESSAGING-1437.
------------------------------------

    Resolution: Done


fixed in the trunk

> Browsers should iterate on queue
> --------------------------------
>
>                 Key: JBMESSAGING-1437
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1437
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>         Attachments: patch-JBMESSAGING-1437.txt
>
>
> Currently the server browser implementation is taking a snapshot of the queue and browsing that. Instead we should implement an iterator on the queue which allows refs to be added or removed from the ends without affecting it.
> This is also necessary to allow failover for browsers which is very hard to implement with the current snapshot approach

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 08:54:56 2009
From: jira-events at lists.jboss.org (Jesus Menendez (JIRA))
Date: Wed, 24 Jun 2009 08:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7053)
 org.jboss.security.jacc.SubjectPolicyContexthandler looking two levels up
 into RunAsIdentity stack
Message-ID: <20739813.1245848096552.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.security.jacc.SubjectPolicyContexthandler looking two levels up into RunAsIdentity stack
--------------------------------------------------------------------------------------------------

                 Key: JBAS-7053
                 URL: https://jira.jboss.org/jira/browse/JBAS-7053
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.2.3.GA, JBossAS-4.2.2.GA
            Reporter: Jesus Menendez
            Assignee: Anil Saldhana



Connfiguration of EJB is
ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee">
  <enterprise-beans>
    <session> 
         <ejb-name>editors</ejb-name>
         <mapped-name>ejb/assethouse/goya/process/agents/editors</mapped-name>
         <business-local>com.assethouse.goya.process.agent.Agent</business-local>
         <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
         <session-type>Stateless</session-type>
         <timeout-method>
              <method-name>startTask</method-name>
         </timeout-method>
         <security-identity>
            <run-as>
                <description>Group for editors Partition</description>
                <role-name>editors</role-name>
            </run-as>
         </security-identity>
      </session>
     <session>
         <ejb-name>publishers</ejb-name>
        <mapped-name>ejb/assethouse/goya/process/agents/publishers</mapped-name>
        <business-local>com.assethouse.goya.process.agent.Agent</business-local>
        <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
        <session-type>Stateless</session-type>
        <timeout-method>
           <method-name>startTask</method-name>
           </timeout-method>
        <security-identity>
           <run-as>
               <description>Group for publishers Partition</description>
               <role-name>publishers</role-name>
           </run-as>
        </security-identity>
     </session>
     
</enterprise-beans>
<assembly-descriptor>
   <security-role>
       <role-name>editors</role-name>
    </security-role>
    <security-role>
        <role-name>publisher</role-name>
     </security-role>
  </assembly-descriptor>
</ejb-jar>



jboss.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC
    "-//JBoss//DTD JBOSS 4_2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">

<jboss>

    <security-domain>java:/jaas/process</security-domain>
    
    <enterprise-beans>
        <session>
            <ejb-name>editors</ejb-name>
            <security-identity>
                <run-as-principal>editor</run-as-principal>
            </security-identity>
        </session>

        <session>
            <ejb-name>publishers</ejb-name>
            <security-identity>
                <run-as-principal>publisher</run-as-principal>
            </security-identity>
        </session>

    </enterprise-beans>

    <assembly-descriptor>
        <security-role>
            <role-name>publishers</role-name>
            <principal-name>publisher</principal-name>
        </security-role>
        <security-role>
            <role-name>editors</role-name>
            <principal-name>editor</principal-name>
        </security-role>
    </assembly-descriptor>

</jboss>


Also configured the login-module with a new security domain with an UserRoleLoginModule plugin

roles.properties
   publisher=publishers
   editor=editors

user.properties
     publisher=password
     editor=password


When I use PolicyContext.getContext("") within and AgentBean method it should return the RunAsIdentity of that method as declared in the run-as . it returns anonymous wihch is the current authenticated user.. not the one specified in run-as

When I looked at the source code  in org.jboss.security.jacc.SubjectPolicyContexthandler
I saw this method call in  lines 55 and 73
RunAsIdentity callerRunAsIdentity = (RunAsIdentity)
               SecurityAssociation.peekRunAsIdentity(1);

What I did is to change the parameter from a value of 1 to a value of 0 so it peeks the top element in the stack
I patched Jboss with this modification and the PolicyContext.getContext("") started returning the right values (editors and publishers)

So, do you think this is a bug in org.jboss.security.jacc.SubjectPolicyContexthandler
Why SecurityAssociation.peekRunAsIdentity is it being called with a parameter value of 1. That is looking two levels down in the stack isn't it? 



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 08:58:56 2009
From: jira-events at lists.jboss.org (Jesus Menendez (JIRA))
Date: Wed, 24 Jun 2009 08:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7053)
 org.jboss.security.jacc.SubjectPolicyContexthandler looking two levels up
 into RunAsIdentity stack
In-Reply-To: <20739813.1245848096552.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22640578.1245848336778.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jesus Menendez updated JBAS-7053:
---------------------------------

    Description: 
I configured two EJBs to make use of the run-as security identity tag
The EJBS implement a class called AgentBean

When I use PolicyContext.getContext("javax.security.auth.Subject.container") within and AgentBean method it should return the RunAsIdentity of that method as declared in the run-as tag . it returns anonymous wihch is the current authenticated user.. not the one specified in run-as


When I looked at the source code  in org.jboss.security.jacc.SubjectPolicyContexthandler
I saw this method call in  lines 55 and 73
RunAsIdentity callerRunAsIdentity = (RunAsIdentity)
               SecurityAssociation.peekRunAsIdentity(1);

What I did is to change the parameter from a value of 1 to a value of 0 so it peeks the top element in the stack
I patched Jboss with this modification and the PolicyContext.getContext("javax.security.auth.Subject.container") started returning the right values (editors and publishers)

So, do you think this is a bug in org.jboss.security.jacc.SubjectPolicyContexthandler
Why SecurityAssociation.peekRunAsIdentity is it being called with a parameter value of 1. That is looking two levels down in the stack isn't it? 




Connfiguration of EJB is
ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee">
  <enterprise-beans>
    <session> 
         <ejb-name>editors</ejb-name>
         <mapped-name>ejb/assethouse/goya/process/agents/editors</mapped-name>
         <business-local>com.assethouse.goya.process.agent.Agent</business-local>
         <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
         <session-type>Stateless</session-type>
         <timeout-method>
              <method-name>startTask</method-name>
         </timeout-method>
         <security-identity>
            <run-as>
                <description>Group for editors Partition</description>
                <role-name>editors</role-name>
            </run-as>
         </security-identity>
      </session>
     <session>
         <ejb-name>publishers</ejb-name>
        <mapped-name>ejb/assethouse/goya/process/agents/publishers</mapped-name>
        <business-local>com.assethouse.goya.process.agent.Agent</business-local>
        <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
        <session-type>Stateless</session-type>
        <timeout-method>
           <method-name>startTask</method-name>
           </timeout-method>
        <security-identity>
           <run-as>
               <description>Group for publishers Partition</description>
               <role-name>publishers</role-name>
           </run-as>
        </security-identity>
     </session>
     
</enterprise-beans>
<assembly-descriptor>
   <security-role>
       <role-name>editors</role-name>
    </security-role>
    <security-role>
        <role-name>publisher</role-name>
     </security-role>
  </assembly-descriptor>
</ejb-jar>



jboss.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC
    "-//JBoss//DTD JBOSS 4_2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">

<jboss>

    <security-domain>java:/jaas/process</security-domain>
    
    <enterprise-beans>
        <session>
            <ejb-name>editors</ejb-name>
            <security-identity>
                <run-as-principal>editor</run-as-principal>
            </security-identity>
        </session>

        <session>
            <ejb-name>publishers</ejb-name>
            <security-identity>
                <run-as-principal>publisher</run-as-principal>
            </security-identity>
        </session>

    </enterprise-beans>

    <assembly-descriptor>
        <security-role>
            <role-name>publishers</role-name>
            <principal-name>publisher</principal-name>
        </security-role>
        <security-role>
            <role-name>editors</role-name>
            <principal-name>editor</principal-name>
        </security-role>
    </assembly-descriptor>

</jboss>


Also configured the login-module with a new security domain with an UserRoleLoginModule plugin

roles.properties
   publisher=publishers
   editor=editors

user.properties
     publisher=password
     editor=password




  was:

Connfiguration of EJB is
ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee">
  <enterprise-beans>
    <session> 
         <ejb-name>editors</ejb-name>
         <mapped-name>ejb/assethouse/goya/process/agents/editors</mapped-name>
         <business-local>com.assethouse.goya.process.agent.Agent</business-local>
         <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
         <session-type>Stateless</session-type>
         <timeout-method>
              <method-name>startTask</method-name>
         </timeout-method>
         <security-identity>
            <run-as>
                <description>Group for editors Partition</description>
                <role-name>editors</role-name>
            </run-as>
         </security-identity>
      </session>
     <session>
         <ejb-name>publishers</ejb-name>
        <mapped-name>ejb/assethouse/goya/process/agents/publishers</mapped-name>
        <business-local>com.assethouse.goya.process.agent.Agent</business-local>
        <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
        <session-type>Stateless</session-type>
        <timeout-method>
           <method-name>startTask</method-name>
           </timeout-method>
        <security-identity>
           <run-as>
               <description>Group for publishers Partition</description>
               <role-name>publishers</role-name>
           </run-as>
        </security-identity>
     </session>
     
</enterprise-beans>
<assembly-descriptor>
   <security-role>
       <role-name>editors</role-name>
    </security-role>
    <security-role>
        <role-name>publisher</role-name>
     </security-role>
  </assembly-descriptor>
</ejb-jar>



jboss.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC
    "-//JBoss//DTD JBOSS 4_2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">

<jboss>

    <security-domain>java:/jaas/process</security-domain>
    
    <enterprise-beans>
        <session>
            <ejb-name>editors</ejb-name>
            <security-identity>
                <run-as-principal>editor</run-as-principal>
            </security-identity>
        </session>

        <session>
            <ejb-name>publishers</ejb-name>
            <security-identity>
                <run-as-principal>publisher</run-as-principal>
            </security-identity>
        </session>

    </enterprise-beans>

    <assembly-descriptor>
        <security-role>
            <role-name>publishers</role-name>
            <principal-name>publisher</principal-name>
        </security-role>
        <security-role>
            <role-name>editors</role-name>
            <principal-name>editor</principal-name>
        </security-role>
    </assembly-descriptor>

</jboss>


Also configured the login-module with a new security domain with an UserRoleLoginModule plugin

roles.properties
   publisher=publishers
   editor=editors

user.properties
     publisher=password
     editor=password


When I use PolicyContext.getContext("") within and AgentBean method it should return the RunAsIdentity of that method as declared in the run-as . it returns anonymous wihch is the current authenticated user.. not the one specified in run-as

When I looked at the source code  in org.jboss.security.jacc.SubjectPolicyContexthandler
I saw this method call in  lines 55 and 73
RunAsIdentity callerRunAsIdentity = (RunAsIdentity)
               SecurityAssociation.peekRunAsIdentity(1);

What I did is to change the parameter from a value of 1 to a value of 0 so it peeks the top element in the stack
I patched Jboss with this modification and the PolicyContext.getContext("") started returning the right values (editors and publishers)

So, do you think this is a bug in org.jboss.security.jacc.SubjectPolicyContexthandler
Why SecurityAssociation.peekRunAsIdentity is it being called with a parameter value of 1. That is looking two levels down in the stack isn't it? 





> org.jboss.security.jacc.SubjectPolicyContexthandler looking two levels up into RunAsIdentity stack
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7053
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7053
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.3.GA
>            Reporter: Jesus Menendez
>            Assignee: Anil Saldhana
>
> I configured two EJBs to make use of the run-as security identity tag
> The EJBS implement a class called AgentBean
> When I use PolicyContext.getContext("javax.security.auth.Subject.container") within and AgentBean method it should return the RunAsIdentity of that method as declared in the run-as tag . it returns anonymous wihch is the current authenticated user.. not the one specified in run-as
> When I looked at the source code  in org.jboss.security.jacc.SubjectPolicyContexthandler
> I saw this method call in  lines 55 and 73
> RunAsIdentity callerRunAsIdentity = (RunAsIdentity)
>                SecurityAssociation.peekRunAsIdentity(1);
> What I did is to change the parameter from a value of 1 to a value of 0 so it peeks the top element in the stack
> I patched Jboss with this modification and the PolicyContext.getContext("javax.security.auth.Subject.container") started returning the right values (editors and publishers)
> So, do you think this is a bug in org.jboss.security.jacc.SubjectPolicyContexthandler
> Why SecurityAssociation.peekRunAsIdentity is it being called with a parameter value of 1. That is looking two levels down in the stack isn't it? 
> Connfiguration of EJB is
> ejb-jar.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <ejb-jar version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee">
>   <enterprise-beans>
>     <session> 
>          <ejb-name>editors</ejb-name>
>          <mapped-name>ejb/assethouse/goya/process/agents/editors</mapped-name>
>          <business-local>com.assethouse.goya.process.agent.Agent</business-local>
>          <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
>          <session-type>Stateless</session-type>
>          <timeout-method>
>               <method-name>startTask</method-name>
>          </timeout-method>
>          <security-identity>
>             <run-as>
>                 <description>Group for editors Partition</description>
>                 <role-name>editors</role-name>
>             </run-as>
>          </security-identity>
>       </session>
>      <session>
>          <ejb-name>publishers</ejb-name>
>         <mapped-name>ejb/assethouse/goya/process/agents/publishers</mapped-name>
>         <business-local>com.assethouse.goya.process.agent.Agent</business-local>
>         <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
>         <session-type>Stateless</session-type>
>         <timeout-method>
>            <method-name>startTask</method-name>
>            </timeout-method>
>         <security-identity>
>            <run-as>
>                <description>Group for publishers Partition</description>
>                <role-name>publishers</role-name>
>            </run-as>
>         </security-identity>
>      </session>
>      
> </enterprise-beans>
> <assembly-descriptor>
>    <security-role>
>        <role-name>editors</role-name>
>     </security-role>
>     <security-role>
>         <role-name>publisher</role-name>
>      </security-role>
>   </assembly-descriptor>
> </ejb-jar>
> jboss.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE jboss PUBLIC
>     "-//JBoss//DTD JBOSS 4_2//EN"
>     "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">
> <jboss>
>     <security-domain>java:/jaas/process</security-domain>
>     
>     <enterprise-beans>
>         <session>
>             <ejb-name>editors</ejb-name>
>             <security-identity>
>                 <run-as-principal>editor</run-as-principal>
>             </security-identity>
>         </session>
>         <session>
>             <ejb-name>publishers</ejb-name>
>             <security-identity>
>                 <run-as-principal>publisher</run-as-principal>
>             </security-identity>
>         </session>
>     </enterprise-beans>
>     <assembly-descriptor>
>         <security-role>
>             <role-name>publishers</role-name>
>             <principal-name>publisher</principal-name>
>         </security-role>
>         <security-role>
>             <role-name>editors</role-name>
>             <principal-name>editor</principal-name>
>         </security-role>
>     </assembly-descriptor>
> </jboss>
> Also configured the login-module with a new security domain with an UserRoleLoginModule plugin
> roles.properties
>    publisher=publishers
>    editor=editors
> user.properties
>      publisher=password
>      editor=password

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 09:01:07 2009
From: jira-events at lists.jboss.org (Jesus Menendez (JIRA))
Date: Wed, 24 Jun 2009 09:01:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7053)
 org.jboss.security.jacc.SubjectPolicyContexthandler looking two levels up
 into RunAsIdentity stack
In-Reply-To: <20739813.1245848096552.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20607412.1245848467276.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Jesus Menendez updated JBAS-7053:
---------------------------------

    Description: 
I configured two EJBs to make use of the run-as security identity tag
The EJBS implement a class called AgentBean

When I use PolicyContext.getContext("javax.security.auth.Subject.container") within and AgentBean method it should return the RunAsIdentity of that method as declared in the run-as tag . it returns anonymous wihch is the current authenticated user.. not the one specified in run-as


When I looked at the source code  in org.jboss.security.jacc.SubjectPolicyContexthandler
I saw this method call in  lines 55 and 73
RunAsIdentity callerRunAsIdentity = (RunAsIdentity)
               SecurityAssociation.peekRunAsIdentity(1);

What I did is to change the parameter from a value of 1 to a value of 0 so it peeks the top element in the stack
I patched Jboss with this modification and the PolicyContext.getContext("javax.security.auth.Subject.container") started returning the right values

So, do you think this is a bug in org.jboss.security.jacc.SubjectPolicyContexthandler
Why SecurityAssociation.peekRunAsIdentity is it being called with a parameter value of 1. That is looking two levels down in the stack isn't it? 




Connfiguration of EJB is
ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee">
  <enterprise-beans>
    <session> 
         <ejb-name>editors</ejb-name>
         <mapped-name>ejb/assethouse/goya/process/agents/editors</mapped-name>
         <business-local>com.assethouse.goya.process.agent.Agent</business-local>
         <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
         <session-type>Stateless</session-type>
         <timeout-method>
              <method-name>startTask</method-name>
         </timeout-method>
         <security-identity>
            <run-as>
                <description>Group for editors Partition</description>
                <role-name>editors</role-name>
            </run-as>
         </security-identity>
      </session>
     <session>
         <ejb-name>publishers</ejb-name>
        <mapped-name>ejb/assethouse/goya/process/agents/publishers</mapped-name>
        <business-local>com.assethouse.goya.process.agent.Agent</business-local>
        <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
        <session-type>Stateless</session-type>
        <timeout-method>
           <method-name>startTask</method-name>
           </timeout-method>
        <security-identity>
           <run-as>
               <description>Group for publishers Partition</description>
               <role-name>publishers</role-name>
           </run-as>
        </security-identity>
     </session>
     
</enterprise-beans>
<assembly-descriptor>
   <security-role>
       <role-name>editors</role-name>
    </security-role>
    <security-role>
        <role-name>publisher</role-name>
     </security-role>
  </assembly-descriptor>
</ejb-jar>



jboss.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC
    "-//JBoss//DTD JBOSS 4_2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">

<jboss>

    <security-domain>java:/jaas/process</security-domain>
    
    <enterprise-beans>
        <session>
            <ejb-name>editors</ejb-name>
            <security-identity>
                <run-as-principal>editor</run-as-principal>
            </security-identity>
        </session>

        <session>
            <ejb-name>publishers</ejb-name>
            <security-identity>
                <run-as-principal>publisher</run-as-principal>
            </security-identity>
        </session>

    </enterprise-beans>

    <assembly-descriptor>
        <security-role>
            <role-name>publishers</role-name>
            <principal-name>publisher</principal-name>
        </security-role>
        <security-role>
            <role-name>editors</role-name>
            <principal-name>editor</principal-name>
        </security-role>
    </assembly-descriptor>

</jboss>


Also configured the login-module with a new security domain with an UserRoleLoginModule plugin

roles.properties
   publisher=publishers
   editor=editors

user.properties
     publisher=password
     editor=password




  was:
I configured two EJBs to make use of the run-as security identity tag
The EJBS implement a class called AgentBean

When I use PolicyContext.getContext("javax.security.auth.Subject.container") within and AgentBean method it should return the RunAsIdentity of that method as declared in the run-as tag . it returns anonymous wihch is the current authenticated user.. not the one specified in run-as


When I looked at the source code  in org.jboss.security.jacc.SubjectPolicyContexthandler
I saw this method call in  lines 55 and 73
RunAsIdentity callerRunAsIdentity = (RunAsIdentity)
               SecurityAssociation.peekRunAsIdentity(1);

What I did is to change the parameter from a value of 1 to a value of 0 so it peeks the top element in the stack
I patched Jboss with this modification and the PolicyContext.getContext("javax.security.auth.Subject.container") started returning the right values (editors and publishers)

So, do you think this is a bug in org.jboss.security.jacc.SubjectPolicyContexthandler
Why SecurityAssociation.peekRunAsIdentity is it being called with a parameter value of 1. That is looking two levels down in the stack isn't it? 




Connfiguration of EJB is
ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee">
  <enterprise-beans>
    <session> 
         <ejb-name>editors</ejb-name>
         <mapped-name>ejb/assethouse/goya/process/agents/editors</mapped-name>
         <business-local>com.assethouse.goya.process.agent.Agent</business-local>
         <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
         <session-type>Stateless</session-type>
         <timeout-method>
              <method-name>startTask</method-name>
         </timeout-method>
         <security-identity>
            <run-as>
                <description>Group for editors Partition</description>
                <role-name>editors</role-name>
            </run-as>
         </security-identity>
      </session>
     <session>
         <ejb-name>publishers</ejb-name>
        <mapped-name>ejb/assethouse/goya/process/agents/publishers</mapped-name>
        <business-local>com.assethouse.goya.process.agent.Agent</business-local>
        <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
        <session-type>Stateless</session-type>
        <timeout-method>
           <method-name>startTask</method-name>
           </timeout-method>
        <security-identity>
           <run-as>
               <description>Group for publishers Partition</description>
               <role-name>publishers</role-name>
           </run-as>
        </security-identity>
     </session>
     
</enterprise-beans>
<assembly-descriptor>
   <security-role>
       <role-name>editors</role-name>
    </security-role>
    <security-role>
        <role-name>publisher</role-name>
     </security-role>
  </assembly-descriptor>
</ejb-jar>



jboss.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC
    "-//JBoss//DTD JBOSS 4_2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">

<jboss>

    <security-domain>java:/jaas/process</security-domain>
    
    <enterprise-beans>
        <session>
            <ejb-name>editors</ejb-name>
            <security-identity>
                <run-as-principal>editor</run-as-principal>
            </security-identity>
        </session>

        <session>
            <ejb-name>publishers</ejb-name>
            <security-identity>
                <run-as-principal>publisher</run-as-principal>
            </security-identity>
        </session>

    </enterprise-beans>

    <assembly-descriptor>
        <security-role>
            <role-name>publishers</role-name>
            <principal-name>publisher</principal-name>
        </security-role>
        <security-role>
            <role-name>editors</role-name>
            <principal-name>editor</principal-name>
        </security-role>
    </assembly-descriptor>

</jboss>


Also configured the login-module with a new security domain with an UserRoleLoginModule plugin

roles.properties
   publisher=publishers
   editor=editors

user.properties
     publisher=password
     editor=password






> org.jboss.security.jacc.SubjectPolicyContexthandler looking two levels up into RunAsIdentity stack
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7053
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7053
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.3.GA
>            Reporter: Jesus Menendez
>            Assignee: Anil Saldhana
>
> I configured two EJBs to make use of the run-as security identity tag
> The EJBS implement a class called AgentBean
> When I use PolicyContext.getContext("javax.security.auth.Subject.container") within and AgentBean method it should return the RunAsIdentity of that method as declared in the run-as tag . it returns anonymous wihch is the current authenticated user.. not the one specified in run-as
> When I looked at the source code  in org.jboss.security.jacc.SubjectPolicyContexthandler
> I saw this method call in  lines 55 and 73
> RunAsIdentity callerRunAsIdentity = (RunAsIdentity)
>                SecurityAssociation.peekRunAsIdentity(1);
> What I did is to change the parameter from a value of 1 to a value of 0 so it peeks the top element in the stack
> I patched Jboss with this modification and the PolicyContext.getContext("javax.security.auth.Subject.container") started returning the right values
> So, do you think this is a bug in org.jboss.security.jacc.SubjectPolicyContexthandler
> Why SecurityAssociation.peekRunAsIdentity is it being called with a parameter value of 1. That is looking two levels down in the stack isn't it? 
> Connfiguration of EJB is
> ejb-jar.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <ejb-jar version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee">
>   <enterprise-beans>
>     <session> 
>          <ejb-name>editors</ejb-name>
>          <mapped-name>ejb/assethouse/goya/process/agents/editors</mapped-name>
>          <business-local>com.assethouse.goya.process.agent.Agent</business-local>
>          <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
>          <session-type>Stateless</session-type>
>          <timeout-method>
>               <method-name>startTask</method-name>
>          </timeout-method>
>          <security-identity>
>             <run-as>
>                 <description>Group for editors Partition</description>
>                 <role-name>editors</role-name>
>             </run-as>
>          </security-identity>
>       </session>
>      <session>
>          <ejb-name>publishers</ejb-name>
>         <mapped-name>ejb/assethouse/goya/process/agents/publishers</mapped-name>
>         <business-local>com.assethouse.goya.process.agent.Agent</business-local>
>         <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
>         <session-type>Stateless</session-type>
>         <timeout-method>
>            <method-name>startTask</method-name>
>            </timeout-method>
>         <security-identity>
>            <run-as>
>                <description>Group for publishers Partition</description>
>                <role-name>publishers</role-name>
>            </run-as>
>         </security-identity>
>      </session>
>      
> </enterprise-beans>
> <assembly-descriptor>
>    <security-role>
>        <role-name>editors</role-name>
>     </security-role>
>     <security-role>
>         <role-name>publisher</role-name>
>      </security-role>
>   </assembly-descriptor>
> </ejb-jar>
> jboss.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE jboss PUBLIC
>     "-//JBoss//DTD JBOSS 4_2//EN"
>     "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">
> <jboss>
>     <security-domain>java:/jaas/process</security-domain>
>     
>     <enterprise-beans>
>         <session>
>             <ejb-name>editors</ejb-name>
>             <security-identity>
>                 <run-as-principal>editor</run-as-principal>
>             </security-identity>
>         </session>
>         <session>
>             <ejb-name>publishers</ejb-name>
>             <security-identity>
>                 <run-as-principal>publisher</run-as-principal>
>             </security-identity>
>         </session>
>     </enterprise-beans>
>     <assembly-descriptor>
>         <security-role>
>             <role-name>publishers</role-name>
>             <principal-name>publisher</principal-name>
>         </security-role>
>         <security-role>
>             <role-name>editors</role-name>
>             <principal-name>editor</principal-name>
>         </security-role>
>     </assembly-descriptor>
> </jboss>
> Also configured the login-module with a new security domain with an UserRoleLoginModule plugin
> roles.properties
>    publisher=publishers
>    editor=editors
> user.properties
>      publisher=password
>      editor=password

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 09:19:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Wed, 24 Jun 2009 09:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
Message-ID: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>

Wrong deployers ordering when multiple inputs specified on many deployers
-------------------------------------------------------------------------

                 Key: JBDEPLOY-201
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
             Project: JBoss Deployers
          Issue Type: Bug
          Components: deployer
    Affects Versions: JBDEPLOY-2.0.8.GA
            Reporter: Richard Opalka
             Fix For:  JBDEPLOY-2.2.x




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 09:23:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Wed, 24 Jun 2009 09:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23015866.1245849836463.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473604#action_12473604 ] 

Richard Opalka commented on JBDEPLOY-201:
-----------------------------------------

[/home/opalka][/opt/svn/jbossas/projects/jboss-deployers/trunk/deployers-impl]>svn ci -m "[JBDEPLOY-201] providing test case"
Sending        deployers-impl/src/test/java/org/jboss/test/deployers/deployer/test/DeployerFlowUnitTestCase.java
Transmitting file data .
Committed revision 90554.

> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 09:41:56 2009
From: jira-events at lists.jboss.org (Marius Bogoevici (JIRA))
Date: Wed, 24 Jun 2009 09:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBVFS-109) Trying to access
 all classpath
 resources from a web application fails due to VFS errors
In-Reply-To: <14030842.1241499346657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23250123.1245850916631.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBVFS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473608#action_12473608 ] 

Marius Bogoevici commented on JBVFS-109:
----------------------------------------

Naresh, 

for a solution to the classpath scanning problem, please refer to http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239767#4239767

This issue is strictly addressing the incorrect internal VFS behaviour and has nothing to do with Spring per se.

Marius

> Trying to access all classpath resources from a web application fails due to VFS errors
> ---------------------------------------------------------------------------------------
>
>                 Key: JBVFS-109
>                 URL: https://jira.jboss.org/jira/browse/JBVFS-109
>             Project: JBoss VFS
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>            Reporter: Marius Bogoevici
>            Assignee: Ales Justin
>             Fix For: 2.1.2.GA
>
>         Attachments: spring-jboss-jaxws.tar.gz
>
>
> The error has been triggered by using classpath scanning in Spring, but can be reproduced independently.
> The code in the servlet listed below does virtually the same thing as the VFSResourcePatternResolver:
> public class BasicServlet extends HttpServlet{
>     @Override
>     protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
>         ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
>         Enumeration<URL> urls = classLoader.getResources("");
>         StringBuffer buffer = new StringBuffer();
>         while (urls.hasMoreElements()) {
>             URL url = urls.nextElement();
>             VirtualFile file = VFS.getRoot(url);
>             buffer.append(file.getPathName() + "\n");
>         }
>         new PrintWriter(resp.getOutputStream()).println(buffer.toString());
>     }
> }
> Trying to access the servlet results in an error when one URL is converted to a VirtualFile by VFS.getRoot(), and here is the resulting exception. The URL that triggers the error differs if the test is repeated.
> 00:45:44,380 ERROR [[resource-servlet]] Servlet.service() for servlet resource-servlet threw exception
> java.io.IOException: Child not found opt/jboss/jboss-5.0.1.GA/server/default/deployers/jbossws.deployer/policy.jar/ for MemoryContextHandler at 555514482[path= context=vfsmemory://3j011-j4xs2m-fuc3y7a8-1-fuc3yl41-9 real=vfsmemory://3j011-j4xs2m-fuc3y7a8-1-fuc3yl41-9], available children: []
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.findHandler(DefaultVFSRegistry.java:109)
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:88)
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:121)
> 	at org.jboss.virtual.VFS.getRoot(VFS.java:276)
> 	at BasicServlet.doGet(BasicServlet.java:22)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 10:04:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 24 Jun 2009 10:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6534180.1245852296843.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473612#action_12473612 ] 

Alexey Loubyansky commented on JBXB-206:
----------------------------------------

If I start current AS trunk, looking into the logs, I don't see any call to org.jboss.xb.binding.Util#loadSchema(java.io.InputStream, String, org.jboss.xb.binding.sunday.unmarshalling.SchemaBindingResolver).

> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>         Attachments: jboss-profiler.properties, jbossxb.zip, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 10:45:56 2009
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Wed, 24 Jun 2009 10:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1000) COMPRESS corrupts
	some messages
Message-ID: <7560851.1245854756549.JavaMail.jira@cloud.prod.atl2.jboss.com>

COMPRESS corrupts some messages
-------------------------------

                 Key: JGRP-1000
                 URL: https://jira.jboss.org/jira/browse/JGRP-1000
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.4.5
            Reporter: Dennis Reed
            Assignee: Dennis Reed


COMPRESS.down() stores the compressed message in a temporary buffer the same size as the original message.

If the compressed size of a message is larger than the original, then part of the message is lost, with no errors reported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 10:48:58 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 24 Jun 2009 10:48:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7050) Unable to create
 any kind of datasource or connection factory
Message-ID: <32789699.1245854938555.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer commented on JBAS-7050:
------------------------------------

I've updated the client code at https://svn.jboss.org/repos/jopr/trunk/etc/jbas5-ejb-client/ to reproduce this.


> Unable to create any kind of datasource or connection factory
> -------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 10:50:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 24 Jun 2009 10:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7050) Unable to create any
 kind of datasource or connection factory
Message-ID: <7067917.1245855057590.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-7050:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> Unable to create any kind of datasource or connection factory
> -------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 10:50:57 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 24 Jun 2009 10:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19758451.1245855057038.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473626#action_12473626 ] 

Jesper Pedersen commented on JBXB-206:
--------------------------------------

This is not AS - I'm using the XB API directly:

MutableSchemaResolver msr = new MultiClassSchemaResolver();


> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>         Attachments: jboss-profiler.properties, jbossxb.zip, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 11:04:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 24 Jun 2009 11:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7052) when invoked from
 remote client, 
 call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15335337.1245855896741.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-7052:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 11:06:58 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 24 Jun 2009 11:06:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17125844.1245856018335.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Ian Springer updated JBAS-7051:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         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.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         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.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.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         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.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 11:35:57 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 24 Jun 2009 11:35:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-740) More workarounds for
 bug in IBM's Class.getDeclaringClass() implementation
In-Reply-To: <10151921.1245758756509.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16931186.1245857757225.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Kabir Khan closed JBAOP-740.
----------------------------

    Resolution: Done
      Assignee: Kabir Khan


> More workarounds for bug in IBM's Class.getDeclaringClass() implementation
> --------------------------------------------------------------------------
>
>                 Key: JBAOP-740
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-740
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.2.GA
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 2.1.3.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 11:57:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 24 Jun 2009 11:57:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <736877.1245859077129.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Shelly McGowan updated JBAS-7049:
---------------------------------


Anil, this also fails on branch JBPAPP_5_0.

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 12:11:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Wed, 24 Jun 2009 12:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-123) Use QA databases for
 sql scripts creation
In-Reply-To: <4718364.1243587716425.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11161236.1245859916701.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Yu updated JBID-123:
-------------------------

    Fix Version/s: idm-1.0.0.Beta1
                       (was: idm-1.0.0.CR1)


> Use QA databases for sql scripts creation
> -----------------------------------------
>
>                 Key: JBID-123
>                 URL: https://jira.jboss.org/jira/browse/JBID-123
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Boleslaw Dawidowicz
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> Distro module should use QA databases to generate schema sql scripts instead of local urls. This will let to generate whole range of sql scripts for all currently tested DBs during release process.
> QA database setup is specified in those files:
> http://anonsvn.jboss.org/repos/jbossidentity/idm/tags/1.0.0.Alpha7/idm-testsuite/src/test/resources/datasources/datasources.xml
> http://anonsvn.jboss.org/repos/jbossidentity/idm/tags/1.0.0.Alpha7/idm-testsuite/src/test/resources/datasources/hibernates.xml

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 12:11:57 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Wed, 24 Jun 2009 12:11:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-99) Unique attributes
In-Reply-To: <3795253.1242040366371.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28527240.1245859917145.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Yu updated JBID-99:
------------------------

    Fix Version/s: idm-1.0.0.Beta1
                       (was: idm-1.0.0.Beta2)


> Unique attributes
> -----------------
>
>                 Key: JBID-99
>                 URL: https://jira.jboss.org/jira/browse/JBID-99
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Boleslaw Dawidowicz
>            Assignee: Boleslaw Dawidowicz
>             Fix For: idm-1.0.0.Beta1
>
>
> Add possibility to mark attribute as unique. This means that given the value is unique in scope of IdentityObjectType (for Users or within given GroupType). There should be an API to query single User or Group based on such attribute value. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 11:31:08 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 24 Jun 2009 11:31:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6877) EJB3 Entity Cache
	Metrics
In-Reply-To: <13995931.1241642506748.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3842157.1245857468160.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned JBAS-6877:
--------------------------------------

    Assignee: Filip Drabek  (was: Brian Stansberry)


Assigning this to Filip Drabek, as he is handling JOPR-221, which is where the real work is actually happening. Feel free to assign back to me if there is something I need to do.

> EJB3 Entity Cache Metrics
> -------------------------
>
>                 Key: JBAS-6877
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6877
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>            Reporter: Andrew Lee Rubinger
>            Assignee: Filip Drabek
>             Fix For: Backlog
>
>
> These statistics must be reflected in the admin-console/Jopr.
> Split from JBAS-6624:
> EJB3 Entity Tree Cache (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache-->
> <metric property="NumberOfLocksHeld" displayType="summary"/>
>          <metric property="NumberOfNodes" displayType="summary"/>
> EJB3 Entity Tree Cache Interceptor (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache,treecache-interceptor=CacheMgmtInterceptor-->
>             <metric property="HitMissRatio" displayType="summary" units="percentage"
>                     description="Returns the hit/miss ratio for the cache. This ratio is defined as hits/(hits + misses)."/>
>             <metric property="ReadWriteRatio" displayType="summary" units="percentage"
>                     description="Returns the read/write ratio for the cache. This ratio is defined as (hits + misses)/stores."/>
>             <metric property="Hits" displayType="summary"/>
>             <metric property="Misses" displayType="summary"/>
>             <metric property="Evictions" displayType="summary"/>
>             <metric property="NumberOfLocksHeld"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="AverageWriteTime" units="milliseconds"/>
>             <metric property="TimeSinceReset" units="seconds"/>
>             <metric property="AverageReadTime" units="milliseconds"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="Stores"/>
>             <metric property="NumberOfAttributes"/>
>             <metric property="ElapsedTime" units="milliseconds"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 13:04:10 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 24 Jun 2009 13:04:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-5615) Synchronization
 mutex for clustered environments
In-Reply-To: <31351334.1213134137427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11282597.1245863050753.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated JBAS-5615:
-------------------------------

    Attachment: potentialPatch.txt


Test patch, this may not be the final change.

> Synchronization mutex for clustered environments
> ------------------------------------------------
>
>                 Key: JBAS-5615
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5615
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: Nick Belaevski
>            Assignee: Scott Marlow
>            Priority: Minor
>         Attachments: potentialPatch.txt
>
>
> Quote from http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136590 : "they'll need to be thread safe or have access to them synchronized".
> There's no object to synchronize against: SessionBasedClusteredSession doesn synchronization against itself:
>    public void writeExternal(ObjectOutput out) throws IOException
>    {
>       synchronized (this)
>       {
>          ...
>      }   
>    
>    } 
> but application developers see the wrapped one (instance of StandardSessionFacade), so synchronizing against session object does not prevent from concurrency errors

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 14:06:58 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 24 Jun 2009 14:06:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2139) Metaheuristic
 solver: research and development
Message-ID: <9566105.1245866818073.JavaMail.jira@cloud.prod.atl2.jboss.com>

Metaheuristic solver: research and development
----------------------------------------------

                 Key: JBRULES-2139
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2139
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-solver
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet


Bilgin reported better results with metaheuristics on the PAS problem then tabu search, so it will probably be a good idea to implement a metaheuristics solver.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 14:08:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 24 Jun 2009 14:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2139) Metaheuristic
 solver: research and development
In-Reply-To: <9566105.1245866818073.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4364749.1245866936431.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473669#action_12473669 ] 

Geoffrey De Smet commented on JBRULES-2139:
-------------------------------------------

How does this relate to phasing? Phasing is the process where you run 10 minutes tabu search, 10 minutes simulated annealing, 10 minutes great deluge, 10 minutes tabu search, ... sequentially after one another on the same problem continue-ing on the results of the previous solver.

> Metaheuristic solver: research and development
> ----------------------------------------------
>
>                 Key: JBRULES-2139
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2139
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>
> Bilgin reported better results with metaheuristics on the PAS problem then tabu search, so it will probably be a good idea to implement a metaheuristics solver.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 14:10:58 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 24 Jun 2009 14:10:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2139) Hyperheuristic
 solver: research and development
In-Reply-To: <9566105.1245866818073.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8179812.1245867058881.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated JBRULES-2139:
--------------------------------------

        Summary: Hyperheuristic solver: research and development  (was: Metaheuristic solver: research and development)
    Description: Bilgin reported better results with a hyperheuristic on the PAS problem then tabu search, so it will probably be a good idea to implement a metaheuristics solver.  (was: Bilgin reported better results with metaheuristics on the PAS problem then tabu search, so it will probably be a good idea to implement a metaheuristics solver.)


> Hyperheuristic solver: research and development
> -----------------------------------------------
>
>                 Key: JBRULES-2139
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2139
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>
> Bilgin reported better results with a hyperheuristic on the PAS problem then tabu search, so it will probably be a good idea to implement a metaheuristics solver.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 15:16:57 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 24 Jun 2009 15:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7013) Seam Booking
 IOException with JSF2 Beta1 on AS5
In-Reply-To: <23174748.1244831337615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2364706.1245871017502.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473688#action_12473688 ] 

Stan Silvert commented on JBAS-7013:
------------------------------------

Opened Mojarra issue for this.  See https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1173

> Seam Booking IOException with JSF2 Beta1 on AS5
> -----------------------------------------------
>
>                 Key: JBAS-7013
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7013
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>
> I drop-in replaced JSF in AS5.1 with JSF 2 Beta 1.  
> With the Seam Booking demo, I bundle the old facelets and have:
>    <context-param>
>       <param-name>javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER</param-name>
>       <param-value>true</param-value>
>     </context-param>
> I get the stack trace below.  Though it doesn't seem to affect the application, I need to figure out why this is happening.
> 13:38:34,463 ERROR [compiler] Error Loading Library: vfszip:/C:/jboss-5.1.0.GA/s
> erver/default/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.tag
> lib.xml
> java.io.IOException: Error parsing [vfszip:/C:/jboss-5.1.0.GA/server/default/dep
> loy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.taglib.xml]:
>         at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.ja
> va:410)
>         at com.sun.facelets.compiler.TagLibraryConfig.loadImplicit(TagLibraryCon
> fig.java:431)
>         at com.sun.facelets.compiler.Compiler.initialize(Compiler.java:87)
>         at com.sun.facelets.compiler.Compiler.compile(Compiler.java:104)
>         at com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFace
> letFactory.java:218)
>         at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFacelet
> Factory.java:149)
>         at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFacelet
> Factory.java:100)
>         at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java
> :517)
>         at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.jav
> a:567)
>         at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWra
> pper.java:108)
>         at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.j
> ava:216)
>         at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePha
> se.java:124)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:103)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:311)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFi
> lter.java:96)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> alve.java:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> alve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(Securit
> yAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValv
> e.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.proce
> ss(SecurityContextEstablishmentValve.java:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invok
> e(SecurityContextEstablishmentValve.java:70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> ava:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> ava:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedC
> onnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> ve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
> a:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
> :829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
> ss(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44
> 7)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: org.xml.sax.SAXException: Error Handling [vfszip:/C:/jboss-5.1.0.GA/s
> erver/default/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.tag
> lib.xml at 42,29]
>         at com.sun.facelets.compiler.TagLibraryConfig$LibraryHandler.error(TagLi
> braryConfig.java:376)
>         at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
>         at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>         at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>         at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>         at org.apache.xerces.impl.dtd.XMLDTDValidator.rootElementSpecified(Unkno
> wn Source)
>         at org.apache.xerces.impl.dtd.XMLDTDValidator.handleStartElement(Unknown
>  Source)
>         at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Sourc
> e)
>         at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElemen
> t(Unknown Source)
>         at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanR
> ootElementHook(Unknown Source)
>         at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
> Dispatcher.dispatch(Unknown Source)
>         at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un
> known Source)
>         at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>         at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>         at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>         at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
>         at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Sour
> ce)
>         at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
>         at javax.xml.parsers.SAXParser.parse(SAXParser.java:198)
>         at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.ja
> va:407)
>         ... 54 more
> Caused by: org.xml.sax.SAXParseException: Document root element "facelet-taglib"
> , must match DOCTYPE root "null".
>         at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Un
> known Source)
>         ... 73 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 15:24:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 24 Jun 2009 15:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7055)
 testValidateSBMContent having problems with hostnames
Message-ID: <3567712.1245871496476.JavaMail.jira@cloud.prod.atl2.jboss.com>

testValidateSBMContent having problems with hostnames 
------------------------------------------------------

                 Key: JBAS-7055
                 URL: https://jira.jboss.org/jira/browse/JBAS-7055
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
         Environment: Solaris 9/10 both x86 and sparc
HPUX both ia64 and risc 
            Reporter: Richard Achmatowicz
            Assignee: Scott M Stark
            Priority: Minor


See the JBPAPP-2139 issue for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 17:17:57 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Wed, 24 Jun 2009 17:17:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-124) Implement WS-T SAML
 Token Profile:: SAMLV2.0 validation
In-Reply-To: <26312958.1243987260389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22673563.1245878277225.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen reopened JBID-124:
---------------------------------



Reopening as the token signature validation needs to be moved to the request handler.

> Implement WS-T SAML Token Profile:: SAMLV2.0 validation
> -------------------------------------------------------
>
>                 Key: JBID-124
>                 URL: https://jira.jboss.org/jira/browse/JBID-124
>             Project: JBoss Identity
>          Issue Type: Sub-task
>          Components: Identity-Federation
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha3
>
>
> The SAML token provider must be able to validate the assertions it generates. This involves validating the digital signature and also the assertion validity period (lifetime).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 17:30:56 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Wed, 24 Jun 2009 17:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-124) Implement WS-T SAML
 Token Profile:: SAMLV2.0 validation
In-Reply-To: <26312958.1243987260389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27933085.1245879056541.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen closed JBID-124.
-------------------------------

    Resolution: Done


Security token are now signed by the request handler. The digital signature validation code has also been moved to the handler, as it is a common validation procedure that applies to most (if not all) types of tokens. Tests have been updated to reflect the changes.

The WSTrustJAXBFactory now preserves any token elements from JAXB (un)marshalling to prevent changes to signed elements. This means that:
- when marshalling a JAXB content tree, token elements are removed from the JAXB objects before marshalling. After the JAXB objects are marshalled to a document, the original token elements are inserted in the document.
- when unmarshalling a document, the token elements are stored before the content is unmarshalled. After the JAXB model has been created, the original token elements are inserted as Any types in the appropriate JAXB objects.

This had to be done because JAXB messes with token elements in a way that invalidates the digital signature, causing perfectly valid tokens to be rejected due to signature validation failure.

> Implement WS-T SAML Token Profile:: SAMLV2.0 validation
> -------------------------------------------------------
>
>                 Key: JBID-124
>                 URL: https://jira.jboss.org/jira/browse/JBID-124
>             Project: JBoss Identity
>          Issue Type: Sub-task
>          Components: Identity-Federation
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha3
>
>
> The SAML token provider must be able to validate the assertions it generates. This involves validating the digital signature and also the assertion validity period (lifetime).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 19:41:58 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Wed, 24 Jun 2009 19:41:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1667) MBeans cannot
 have heirarchical names
Message-ID: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>

MBeans cannot have heirarchical names
-------------------------------------

                 Key: JBMESSAGING-1667
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Destination Manager
    Affects Versions: 1.4.4.GA
         Environment: JBoss 5.1.0.GA
            Reporter: Richard Kennard
            Assignee: Tim Fox


In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:

<mbean code="..." name="...,name=app1/emails">

The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.

A workaround proposed on the forums is to use the 'JNDIName' attribute:

<mbean code="..." name="...,name=emails">
   <attribute name="JNDIName">app1/emails</attribute>

This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:

<mbean code="..." name="...,name=emails">
   <attribute name="JNDIName">app1/emails</attribute>

<mbean code="..." name="...,name=emails">
   <attribute name="JNDIName">app2/emails</attribute>

In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 17:45:07 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 24 Jun 2009 17:45:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-531) Build testsuite
 classpaths directly against jars in local maven repository
In-Reply-To: <6026725.1243637396349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23133015.1245879907715.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-531:
------------------------------

    Summary: Build testsuite classpaths directly against jars in local maven repository  (was: Build classpaths directly against jars in local maven repository)


> Build testsuite classpaths directly against jars in local maven repository
> --------------------------------------------------------------------------
>
>                 Key: JBBUILD-531
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-531
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the testsuite uses the jars in thirdparty.  Instead the paths in the testsuite should directly reference jars in the local maven repository directory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 15:18:59 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 24 Jun 2009 15:18:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7054) Allow configuring of
 Manager for distributable webapps via context.xml
Message-ID: <9414961.1245871139577.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow configuring of Manager for distributable webapps via context.xml
----------------------------------------------------------------------

                 Key: JBAS-7054
                 URL: https://jira.jboss.org/jira/browse/JBAS-7054
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-5.2.0.Beta1


TomcatDeployment will currently always replace the session Manager impl for contexts it creates if the distributable flag is set in web.xml.  Add a flag to TomcatDeployer disable this behavior. This will allow use of a Manager configured via context.xml.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 21:51:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 24 Jun 2009 21:51:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2140) Function + MVEL
 dialect == rule firing in error
Message-ID: <7739511.1245894717244.JavaMail.jira@cloud.prod.atl2.jboss.com>

Function + MVEL dialect == rule firing in error
-----------------------------------------------

                 Key: JBRULES-2140
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2140
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


REPORTED BY MICHAL:
---------------------------------------
Hi,

I've encountered a bizarre bug when a function is used together with a declared type and a rule with mvel dialect.

To reproduce create a default 'New Drools Project' in Eclipse and replace Sample.drl with the following:
--------------------------------------------------------------------------
package com.sample
 
function void aaa() { // <----- comment this and it will work
}

declare SomeBean
prop : int
end
 
rule "setup"
dialect "mvel"   // <----- comment this and it will work
when
eval(true)
then
SomeBean someBean = new SomeBean();
insert(someBean);
System.out.println( "setup inserted:" + someBean);
end

rule "should never fire"
salience -20
when
not SomeBean()
then
System.out.println( "rule that should never fire fired !!!" );
end
------------------------------------------------------------------------

Run the DroolsTest.java and see that the last rule that should never fire is actually fired. If you comment out the 'aaa' function or change the dialect to 'java' all works fine.

Note that it breaks on JDK 1.5.0_12 however it works fine on JDK 1.6.0_14.
Tested on WinXP.

Is it just my machine or does anybody else see this issue?

Best regards,
Michal


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 23:41:57 2009
From: jira-events at lists.jboss.org (Naresh Bhatia (JIRA))
Date: Wed, 24 Jun 2009 23:41:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBVFS-109) Trying to access
 all classpath
 resources from a web application fails due to VFS errors
In-Reply-To: <14030842.1241499346657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23174604.1245901317436.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBVFS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473709#action_12473709 ] 

Naresh Bhatia commented on JBVFS-109:
-------------------------------------

Thanks Marius. I tried out the solution and it works beautifully. Keep up the good work!

> Trying to access all classpath resources from a web application fails due to VFS errors
> ---------------------------------------------------------------------------------------
>
>                 Key: JBVFS-109
>                 URL: https://jira.jboss.org/jira/browse/JBVFS-109
>             Project: JBoss VFS
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>            Reporter: Marius Bogoevici
>            Assignee: Ales Justin
>             Fix For: 2.1.2.GA
>
>         Attachments: spring-jboss-jaxws.tar.gz
>
>
> The error has been triggered by using classpath scanning in Spring, but can be reproduced independently.
> The code in the servlet listed below does virtually the same thing as the VFSResourcePatternResolver:
> public class BasicServlet extends HttpServlet{
>     @Override
>     protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
>         ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
>         Enumeration<URL> urls = classLoader.getResources("");
>         StringBuffer buffer = new StringBuffer();
>         while (urls.hasMoreElements()) {
>             URL url = urls.nextElement();
>             VirtualFile file = VFS.getRoot(url);
>             buffer.append(file.getPathName() + "\n");
>         }
>         new PrintWriter(resp.getOutputStream()).println(buffer.toString());
>     }
> }
> Trying to access the servlet results in an error when one URL is converted to a VirtualFile by VFS.getRoot(), and here is the resulting exception. The URL that triggers the error differs if the test is repeated.
> 00:45:44,380 ERROR [[resource-servlet]] Servlet.service() for servlet resource-servlet threw exception
> java.io.IOException: Child not found opt/jboss/jboss-5.0.1.GA/server/default/deployers/jbossws.deployer/policy.jar/ for MemoryContextHandler at 555514482[path= context=vfsmemory://3j011-j4xs2m-fuc3y7a8-1-fuc3yl41-9 real=vfsmemory://3j011-j4xs2m-fuc3y7a8-1-fuc3yl41-9], available children: []
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.findHandler(DefaultVFSRegistry.java:109)
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:88)
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:121)
> 	at org.jboss.virtual.VFS.getRoot(VFS.java:276)
> 	at BasicServlet.doGet(BasicServlet.java:22)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 01:33:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 25 Jun 2009 01:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1667) MBeans
 cannot have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15959369.1245908036727.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1667:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 01:35:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 25 Jun 2009 01:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1667) MBeans cannot
 have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8049898.1245908156622.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1667:
------------------------------------

        Fix Version/s: 1.4.0.SP3.CP09
                       1.4.5.GA
    Affects Version/s: 1.4.0.SP3.CP08


> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 01:38:10 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jun 2009 01:38:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21000674.1245908290037.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reassigned JBDEPLOY-201:
---------------------------------------

    Assignee: Richard Opalka


> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 02:59:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 25 Jun 2009 02:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-214) fix matadata common
	build
In-Reply-To: <26514201.1245811874997.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29596414.1245913196461.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated JBMETA-214:
-------------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 1.0.2.Beta2)


Corrected the fix version.

> fix matadata common build
> -------------------------
>
>                 Key: JBMETA-214
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-214
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 2.0.0.CR1
>
>
> compile matadata/common in JDK5 will be failed
> [INFO] [compiler:compile]
> [INFO] Compiling 182 source files to /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/target/classes
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Compilation failure
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[29,20] package javax.xml.ws does not exist
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/WebServiceHandlerChainProcessor.java:[34,17] package javax.jws does not exist
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[70,69] cannot find symbol
> symbol  : class WebServiceRef
> location: class org.jboss.metadata.annotation.creator.ws.AbstractWebServiceRefProcessor<E>
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[99,55] cannot find symbol
> symbol  : class WebServiceRef
> location: class org.jboss.metadata.annotation.creator.ws.AbstractWebServiceRefProcessor<E>
> .....

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 03:01:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 25 Jun 2009 03:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-206) TESTSUITE:
 externalize schema to class mapping into a properties file
In-Reply-To: <10888381.1244726696753.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14537195.1245913316911.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated JBMETA-206:
-------------------------------------

    Fix Version/s: 2.0.0.CR1


> TESTSUITE: externalize schema to class mapping into a properties file
> ---------------------------------------------------------------------
>
>                 Key: JBMETA-206
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-206
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.0.2.Beta2, 2.0.0.CR1
>
>
> All the mapping is currently done in MetaDataSchemaResolverFactory. Working on the metadata split, this class could be in the common but the mapping would be different for a specific subproject.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 03:01:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 25 Jun 2009 03:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMETA-206) TESTSUITE:
 externalize schema to class mapping into a properties file
In-Reply-To: <10888381.1244726696753.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27963441.1245913316777.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky reopened JBMETA-206:
--------------------------------------



Re-openning to correct the fix version.

> TESTSUITE: externalize schema to class mapping into a properties file
> ---------------------------------------------------------------------
>
>                 Key: JBMETA-206
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-206
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.0.2.Beta2, 2.0.0.CR1
>
>
> All the mapping is currently done in MetaDataSchemaResolverFactory. Working on the metadata split, this class could be in the common but the mapping would be different for a specific subproject.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 03:01:57 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 25 Jun 2009 03:01:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-213) add JCA DTD files
In-Reply-To: <2485970.1245738836463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28419391.1245913317199.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated JBMETA-213:
-------------------------------------

    Fix Version/s: 2.0.0.CR1


> add JCA DTD files
> -----------------
>
>                 Key: JBMETA-213
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-213
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.2.Beta2, 2.0.0.CR1
>
>
> add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/rar

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 03:01:57 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 25 Jun 2009 03:01:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMETA-206) TESTSUITE:
 externalize schema to class mapping into a properties file
In-Reply-To: <10888381.1244726696753.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5874940.1245913317040.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBMETA-206.
------------------------------------

    Resolution: Done


> TESTSUITE: externalize schema to class mapping into a properties file
> ---------------------------------------------------------------------
>
>                 Key: JBMETA-206
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-206
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.0.2.Beta2, 2.0.0.CR1
>
>
> All the mapping is currently done in MetaDataSchemaResolverFactory. Working on the metadata split, this class could be in the common but the mapping would be different for a specific subproject.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 03:03:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 25 Jun 2009 03:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-209) jboss-metadata
 trunk test compilation fails in JDK5
In-Reply-To: <9131641.1245260636508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31032264.1245913436448.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated JBMETA-209:
-------------------------------------

    Fix Version/s: 2.0.0.CR1


> jboss-metadata trunk test compilation fails in JDK5
> ---------------------------------------------------
>
>                 Key: JBMETA-209
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-209
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.0.2.Beta2, 2.0.0.CR1
>
>
> [INFO] Compilation failure
> /home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
> symbol  : method stringPropertyNames()
> location: class java.util.Properties
> /home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
> symbol  : method stringPropertyNames()
> location: class java.util.Properties

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 04:16:00 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 25 Jun 2009 04:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMETA-210) Validation errors in
 some jboss-___.5_x.xsd files
In-Reply-To: <21174263.1245266996482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23955424.1245917760623.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBMETA-210.
------------------------------------

    Fix Version/s: 1.0.2.Beta2
                   2.0.0.CR1
       Resolution: Done


Fixed. Thanks!

> Validation errors in some jboss-___.5_x.xsd files
> -------------------------------------------------
>
>                 Key: JBMETA-210
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-210
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Eclipse 3.4.2/WebToolsPlatform 3.0.4
>            Reporter: Wolfgang Knauf
>            Assignee: Alexey Loubyansky
>             Fix For: 1.0.2.Beta2, 2.0.0.CR1
>
>
> Some more schema definitions for 5.0/5.1 contain validation errors (which will raise validation errors if building instances in Eclipse). The problem is that includes/imports don't point to the web locations.
> The same issue arose for jboss-5.1.xsd: https://jira.jboss.org/jira/browse/JBMETA-200
> jboss-web_5_1.xsd:
>    <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>
>    <xsd:include schemaLocation="jboss-common_5_1.xsd"/>
> Change to:
>    <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>
>    <xsd:include schemaLocation="http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd"/>
> ===================    
> jboss-ds_5_0.xsd:
>    <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>
>    <xsd:include schemaLocation="jboss-common_5_1.xsd"/>
> Change to:
>    <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>
>    <xsd:include schemaLocation="http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd"/>
>    
> ===================    
> jboss-client_5_1.xsd
>    <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>
>    <xsd:include schemaLocation="jboss-common_5_1.xsd"/>
> Change to:
>    <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>
>    <xsd:include schemaLocation="http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd"/>
>    

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 04:34:08 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 25 Jun 2009 04:34:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1667) MBeans cannot
 have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30798819.1245918848307.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1667:
---------------------------------

    Issue Type: Feature Request  (was: Bug)


> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 04:36:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 25 Jun 2009 04:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1667) MBeans
 cannot have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18924926.1245919016903.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473722#action_12473722 ] 

Tim Fox commented on JBMESSAGING-1667:
--------------------------------------

Most messaging systems use the dot '.' not the slash to separate words in hierarchical topics.

This is what I recommend you do, which will already work with JBM 1.x

<mbean code="..." name="...,name=app1.emails">
   <attribute name="JNDIName">app1/emails</attribute> 

<mbean code="..." name="...,name=app2.emails">
   <attribute name="JNDIName">app2/emails</attribute> 

<mbean code="..." name="...,name=app3.subapp2..emails">
   <attribute name="JNDIName">app1/subapp2/emails</attribute> 

> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 04:45:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 25 Jun 2009 04:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23936305.1245919556696.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-201.
----------------------------------

    Resolution: Rejected


> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 04:53:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 25 Jun 2009 04:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1667) MBeans
 cannot have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11174749.1245920036536.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473726#action_12473726 ] 

Tim Fox commented on JBMESSAGING-1667:
--------------------------------------

JBM, ActiveMQ, also any AMQP based system will use dots. JBM 2.0 uses dots too. (see http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/usermanual-2.0.0.beta3/html/wildcard-routing.html )

Using slashes won't allow you to exploit wildcard routing in JBM 2.0 (or ActiveMQ or many other systems for that matter).

I recommend for this task we keep the behaviour as is and explicitly disallow the forward slash character in destination names. We can throw a warning on deploy and not deploy them if they contain the forward slash character.

I am loathed to give special status to the forward slash character that would make it create subcontextes automatically since this goes against the grain of normal conventions for topic hierarchies.

> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 04:59:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 25 Jun 2009 04:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1667) MBeans
 cannot have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31953395.1245920396574.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473727#action_12473727 ] 

Howard Gao commented on JBMESSAGING-1667:
-----------------------------------------

I agree with Tim. 

Howard


> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:18:09 2009
From: jira-events at lists.jboss.org (Michal Bali (JIRA))
Date: Thu, 25 Jun 2009 05:18:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2140) Function + MVEL
 dialect == rule firing in error
In-Reply-To: <7739511.1245894717244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27819240.1245921489247.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473729#action_12473729 ] 

Michal Bali commented on JBRULES-2140:
--------------------------------------

I am not sure if this helps but the example works fine with SNAPSHOT taken at the following time:
drools-core-5.0.0.20090417.044049-485.jar

> Function + MVEL dialect == rule firing in error
> -----------------------------------------------
>
>                 Key: JBRULES-2140
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2140
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> REPORTED BY MICHAL:
> ---------------------------------------
> Hi,
> I've encountered a bizarre bug when a function is used together with a declared type and a rule with mvel dialect.
> To reproduce create a default 'New Drools Project' in Eclipse and replace Sample.drl with the following:
> --------------------------------------------------------------------------
> package com.sample
>  
> function void aaa() { // <----- comment this and it will work
> }
> declare SomeBean
> prop : int
> end
>  
> rule "setup"
> dialect "mvel"   // <----- comment this and it will work
> when
> eval(true)
> then
> SomeBean someBean = new SomeBean();
> insert(someBean);
> System.out.println( "setup inserted:" + someBean);
> end
> rule "should never fire"
> salience -20
> when
> not SomeBean()
> then
> System.out.println( "rule that should never fire fired !!!" );
> end
> ------------------------------------------------------------------------
> Run the DroolsTest.java and see that the last rule that should never fire is actually fired. If you comment out the 'aaa' function or change the dialect to 'java' all works fine.
> Note that it breaks on JDK 1.5.0_12 however it works fine on JDK 1.6.0_14.
> Tested on WinXP.
> Is it just my machine or does anybody else see this issue?
> Best regards,
> Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:21:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jun 2009 05:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16166539.1245921716760.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reopened JBDEPLOY-201:
-------------------------------------



Just give me free hands Ales, please.
I'll fix it because it's blocking issue for me.
I know how to fix it;) You can review my
commits afterwards.

> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:23:57 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jun 2009 05:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26215070.1245921837233.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated JBDEPLOY-201:
------------------------------------

    Comment: was deleted


> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:52:59 2009
From: jira-events at lists.jboss.org (Vicky Kak (JIRA))
Date: Thu, 25 Jun 2009 05:52:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCOMMON-35) NestedThrowable
 Class when accessed concurrently by 2 Threads cause deadlock .
In-Reply-To: <7851949.1191329943789.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15353220.1245923579178.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBCOMMON-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vicky Kak updated JBCOMMON-35:
------------------------------

    Fix Version/s: 1.2.1.GA


> NestedThrowable Class when accessed concurrently by 2 Threads cause deadlock .
> ------------------------------------------------------------------------------
>
>                 Key: JBCOMMON-35
>                 URL: https://jira.jboss.org/jira/browse/JBCOMMON-35
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common-core (2.x), common-old (1.x)
>    Affects Versions: 1.0.0.GA
>            Reporter: Vicky Kak
>            Assignee: Vicky Kak
>             Fix For: 1.2.1.GA, 1.2.2.GA, 1.0.5.GA
>
>
> http://forum.java.sun.com/thread.jspa?threadID=752201

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:54:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 25 Jun 2009 05:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1851) Investigate the
 failure
 org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
In-Reply-To: <10648726.1245161216783.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18970301.1245923696571.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1851.
------------------------------------

                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-metrics-deployer:1.0.0-alpha-11


The test is now passing on mike (starting job#347) after upgrading to jboss-ejb3-metrics-deployer:1.0.0-alpha-11

> Investigate the failure org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
> -------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1851
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1851
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: metrics-deployer, testsuite
>    Affects Versions: 1.1.7
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> The org.jboss.ejb3.test.container.unit.ContainerTestCase consistently fails with:
> javax.naming.NameNotFoundException: Stateful not bound
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
> 	at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
> 	at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> 	at java.lang.Thread.run(Thread.java:595)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> 	at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at org.jboss.ejb3.test.container.unit.ContainerTestCase.testInvocationStatistics(ContainerTestCase.java:93)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
> 	at junit.extensions.TestSetup.run(TestSetup.java:27)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:58:57 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Thu, 25 Jun 2009 05:58:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1612) Provide a
 complete JCA Parmeters override
In-Reply-To: <23605475.1241104013618.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25026705.1245923937230.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1612.
------------------------------------

    Resolution: Done


> Provide a complete JCA Parmeters override
> -----------------------------------------
>
>                 Key: JBMESSAGING-1612
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1612
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 06:46:11 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 25 Jun 2009 06:46:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1001) Use ByteMan /
 Metronome to inject faults for testing
Message-ID: <18204662.1245926771912.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use ByteMan / Metronome to inject faults for testing
----------------------------------------------------

                 Key: JGRP-1001
                 URL: https://jira.jboss.org/jira/browse/JGRP-1001
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


Use ByteMan (jboss.org/byteman) to simulate issues that can happen at runtime: do this in unit tests.
For example: crash of merge leader after initial round (who frees the locks ?) (same for FLUSH)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 06:47:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 25 Jun 2009 06:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13127312.1245926876523.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473749#action_12473749 ] 

Ales Justin commented on JBDEPLOY-201:
--------------------------------------

Can you please not commit before we discuss this on the MC dev forum?
(currently the discussion is on the MC user forum, and you haven't given me any valid arguments)

> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 07:17:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jun 2009 07:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17890110.1245928676642.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473757#action_12473757 ] 

Richard Opalka commented on JBDEPLOY-201:
-----------------------------------------

Sorry for that. I thought I posted it to dev MC forum :(
That explains why I didn't get the notification on your comments.
I'm moving the discussion to the MC dev forum.

> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 07:17:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jun 2009 07:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5360829.1245928676900.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473758#action_12473758 ] 

Richard Opalka commented on JBDEPLOY-201:
-----------------------------------------

Related user forum discussion: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239756

> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 07:23:00 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jun 2009 07:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21051641.1245928980797.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated JBDEPLOY-201:
------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239981  (was: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239756)


> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 08:09:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 25 Jun 2009 08:09:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2136) Simple match
 rule fails on 5.0.1 and works on 4.0.7
In-Reply-To: <17964558.1245745317053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20935041.1245931797374.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned JBRULES-2136:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> Simple match rule fails on 5.0.1 and works on 4.0.7
> ---------------------------------------------------
>
>                 Key: JBRULES-2136
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2136
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Corneil du Plessis
>            Assignee: Edson Tirelli
>            Priority: Critical
>         Attachments: drools-test.zip
>
>
> A simple rule that worked in 4.0.7 fails in 5.0.1
> An Eclipse project to illustrate the problem will be attached to this issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 08:09:57 2009
From: jira-events at lists.jboss.org (Nicolas Heron (JIRA))
Date: Thu, 25 Jun 2009 08:09:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2141) In a rule flow,
 when the action is in MVEL, it is not possible to import classes
Message-ID: <5800231.1245931797780.JavaMail.jira@cloud.prod.atl2.jboss.com>

In a rule flow, when the action is in MVEL, it is not possible to import classes
--------------------------------------------------------------------------------

                 Key: JBRULES-2141
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2141
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse (flow)
    Affects Versions: FUTURE
            Reporter: Nicolas Heron
            Assignee: Mark Proctor


example : 
-----------
Long montant = (Long)context.getVariable("surimposition");
System.out.println ("Surimposition : '" + montant + "'");
 filter = new org.drools.runtime.ClassObjectFilter (fr.sopra.impot.Impot.class);
java.util.Collection impots = context.getKnowledgeRuntime().getObjects(filter);
if (impots.size()==1) {
	Impot impot = (Impot)impots.toArray()[0]; 
	impot.setMontantRedressement(montant);
}
---------------
it says  at design time : 
Process 'ImpotProcess' [fr.sopra.impot.ImpotProcess]: Action node 'Traitement des resultats' [13] has invalid action: was expecting type: java.lang.Object; but found type: null.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 08:17:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 25 Jun 2009 08:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2136) Simple match rule
 fails on 5.0.1 and works on 4.0.7
In-Reply-To: <17964558.1245745317053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15029106.1245932276540.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2136.
----------------------------------

    Resolution: Rejected


Due to some limitations on the way that Drools 4 handles regexps, we had to change the default escaping syntax for regexps, from single escape to double escape. In Drools 5, regexps work exactly like in Java. So, instead of doing:

".*\s(ADDR)\s.*|(ADDR)\s.*|.*\s(ADDR)"

You need to write:

".*\\s(ADDR)\\s.*|(ADDR)\\s.*|.*\\s(ADDR)"

If you would like to continue using regexps in the same way you did for Drools 4, i.e., with single escape (not recommended), there is a configuration that makes Drools 5 parse regexps as it did in Drools 4.
Using the type safe API, you can do:

        KnowledgeBuilderConfiguration config = KnowledgeBuilderFactory.newKnowledgeBuilderConfiguration();
        config.setOption( ProcessStringEscapesOption.NO);
        KnowledgeBuider kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder( conf );

If you prefer to use the property or configuration file, then it is:

drools.parser.processStringEscapes = false



> Simple match rule fails on 5.0.1 and works on 4.0.7
> ---------------------------------------------------
>
>                 Key: JBRULES-2136
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2136
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Corneil du Plessis
>            Assignee: Edson Tirelli
>            Priority: Critical
>         Attachments: drools-test.zip
>
>
> A simple rule that worked in 4.0.7 fails in 5.0.1
> An Eclipse project to illustrate the problem will be attached to this issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 08:32:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 25 Jun 2009 08:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24592319.1245933176587.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin reassigned JBDEPLOY-201:
------------------------------------

    Assignee: Ales Justin  (was: Richard Opalka)


> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Ales Justin
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 08:40:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 25 Jun 2009 08:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1812) @Service beans
 with a @Management interface leave orphan MC beans after undeploy
In-Reply-To: <24300925.1240836886520.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13707683.1245933656519.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1812.
------------------------------------

    Resolution: Out of Date


This is no longer reproducible against JBoss AS 5.1.0 GA. Please upgrade to AS 5.1.0 GA and if you still run into this issue, please bring this up in the forum thread so that we can decide about re-opening this.


> @Service beans with a @Management interface leave orphan MC beans after undeploy
> --------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1812
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1812
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.4
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> If a @Service bean is marked to have a @Management interface, during deployment a MBean is created as well as a MC bean is deployed. However on undeployment, only the MBean is unregistered, leaving back the MC bean. This leads to MC complaining about incomplete deployments due to missing dependencies. Please see the refered forum thread for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 08:50:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jun 2009 08:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22581236.1245934256518.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473777#action_12473777 ] 

Richard Opalka commented on JBDEPLOY-201:
-----------------------------------------

The fix have to include also the following usecase:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157558&postdays=0&postorder=asc&start=10#4239932
and throw exception when such attempt is detected.

> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Ales Justin
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 09:35:58 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 25 Jun 2009 09:35:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6624) EJB3 Session Bean
	metrics
In-Reply-To: <33127819.1237195628532.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28062914.1245936958146.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-6624.
---------------------------------------

    Resolution: Done


> EJB3 Session Bean metrics
> -------------------------
>
>                 Key: JBAS-6624
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6624
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> EJB3 Session Bean metrics (in addition to availability)
>        <!-- ear=rhq.ear,jar=rhq-enterprise-server-ejb.ejb3,name=AgentManagerBean,service=EJB3 -->
>          <!-- jboss.j2ee:jar=SimpleSLSB.jar,name=SimpleSLSB,service=EJB3 -->
>         <metric displayName="Current Count" property="CurrentSize"/>
>          <metric displayName="Create Count" property="CreateCount" displayType="summary" measurementType="trendsup"
>                  description="the number of instances of this EJB that have been created"/>
>          <metric displayName="Remove Count" property="RemoveCount" displayType="summary" measurementType="trendsup"
>                  description="the number of instances of this EJB that have been removed"/>
>          <metric displayName="Available Count" property="AvailableCount"/>
>          <metric displayName="Max Size" property="MaxSize"/>
> Plus the complex method invocation metrics
>  <metric property="InvokeStats" dataType="calltime" units="milliseconds"
>                  defaultOn="false" defaultInterval="600000" destinationType="Method Name"
>                  description="the minimum, maximum, and average invocation times for each of the methods exposed by this EJB;
>                               NOTE: this metric is only available if JBoss EJB3 RC9 Patch 1 or later is being used
>                               (a capable version of EJB3 is included with JBossAS 4.2.0.GA or later)"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 09:37:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 25 Jun 2009 09:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6999) expose MOs for EJB3
 MDBs w/ some metrics
In-Reply-To: <23501033.1244041905722.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13371911.1245937076612.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-6999.
---------------------------------------

    Resolution: Done


> expose MOs for EJB3 MDBs w/ some metrics
> ----------------------------------------
>
>                 Key: JBAS-6999
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6999
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> <pilhuhn> Do you also plan to list MDBs so that they can at least be detected?
> <ALR> pilhuhn: I hadn't, but I can add that.  What would you like exposed for MDB?
> <pilhuhn> metrics like on the jmx console would be cool, but just listing them as ManagedComponent within a EJB jar would be great - they are already in the KnownComponentTypes :)
> <ALR> pilhuhn: To list as a ManagedComponent wouldn't I need to register some @ManagementObject ?  Just some stub thing?
> <pilhuhn> aehm .. :)
> <ALR> pilhuhn: I've found some stats I can expose, actually, without touching the ejb3-core, which has been my aim thus far. :)  I'll do it.
> <pilhuhn> Great - JOPR-203 has a EAR attached with a MDB in it - and the jxm-console shows keepalive millis, stats, min pool size, max pool size, delivery active and max messages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 10:49:56 2009
From: jira-events at lists.jboss.org (jorge middleton (JIRA))
Date: Thu, 25 Jun 2009 10:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2142) import resources
 from Guvnor facilities
Message-ID: <11004318.1245941396633.JavaMail.jira@cloud.prod.atl2.jboss.com>

import resources from Guvnor facilities
---------------------------------------

                 Key: JBRULES-2142
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2142
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
    Affects Versions: 5.0.0.CR1
         Environment: windows
            Reporter: jorge middleton
            Assignee: Mark Proctor
            Priority: Minor


The import facility has not have the posibility to import the complete package even more the posibility to import more than one package. I try to import a complete package but I couldn't because the package also had *.jar files.

Another improvenment is when you have to select where to download the resources previously selected. The window show me all my eclipse projects even those that are closed.

Thanks in advance and sorry for my english.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 11:18:58 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 25 Jun 2009 11:18:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1002) Merge: make the
 coordinator remain the same if possible after a merge
Message-ID: <27996130.1245943138592.JavaMail.jira@cloud.prod.atl2.jboss.com>

Merge: make the coordinator remain the same if possible after a merge
---------------------------------------------------------------------

                 Key: JGRP-1002
                 URL: https://jira.jboss.org/jira/browse/JGRP-1002
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.0


When we have {C, A, B} and split into {C,A} and {B}, then a merge will produce {A,B,C}. Therefore the coord is moved from C to A. For certain apps, e.g. JBoss singletons, this is not good, as we're moving the singleton services from a perfectly healthy node to a different node.
GOAL: come up with a deterministic policy of picking a coord such that we minimize coord switching if the existing coord is still member of the cluster.
This depends on or is related to the flexible coord pick policy JIRA issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:12:08 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Thu, 25 Jun 2009 15:12:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1856) NPE if
 "res-type" element is
 missing in ejb-jar.xml for injection of SessionContext
Message-ID: <8850904.1245957128139.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE if "res-type" element is missing in ejb-jar.xml for injection of SessionContext
-----------------------------------------------------------------------------------

                 Key: EJBTHREE-1856
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1856
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: 1.1.5
            Reporter: Wolfgang Knauf


I have an ejb-jar.xml for an annotation free EJB. I try to inject a SessionContext.

With JBoss 5.0, this snippet worked:
			<resource-ref>
				<res-ref-name>NameDoesNotCare</res-ref-name>
				<mapped-name>java:comp/EJBContext</mapped-name>
				<injection-target>
					<injection-target-class>de.some.package.SecuredBean</injection-target-class>
					<injection-target-name>mySessionContext</injection-target-name>
			  	</injection-target>
			</resource-ref>

With JBoss 5.1, this fails with a NullPointerException (EJB is "SecuredBean" in "SecurityEJB.jar"):

21:02:02,890 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
21:02:02,890 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/C:/temp/jboss-5.1.0.GA/server/default/tmp/jsr88/Security.ear/ state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying SecurityEJB.jar: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
	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:1210)
	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.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:413)
	at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.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 sun.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
	at sun.reflect.GeneratedMethodAccessor304.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
	at sun.reflect.GeneratedMethodAccessor303.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
	at sun.rmi.transport.Transport$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Unknown Source)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.Exception: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
	... 68 more
Caused by: java.lang.NullPointerException
	at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185)
	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335)
	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588)
	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
	... 69 more


I found that "<res-type>javax.ejb.SessionContext</res-type>" is missing. I think the deployment should raise a meaningful error message.

I can provide you with a full sample if required.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:15:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 25 Jun 2009 15:15:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1856) NPE if
 "res-type" element
 is missing in ejb-jar.xml for injection of SessionContext
In-Reply-To: <8850904.1245957128139.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18288686.1245957356994.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473820#action_12473820 ] 

jaikiran pai commented on EJBTHREE-1856:
----------------------------------------

Wolfgang, if you have that sample application, please attach it to the JIRA. Thanks :)

> NPE if "res-type" element is missing in ejb-jar.xml for injection of SessionContext
> -----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1856
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1856
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.5
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>
> I have an ejb-jar.xml for an annotation free EJB. I try to inject a SessionContext.
> With JBoss 5.0, this snippet worked:
> 			<resource-ref>
> 				<res-ref-name>NameDoesNotCare</res-ref-name>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.some.package.SecuredBean</injection-target-class>
> 					<injection-target-name>mySessionContext</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> With JBoss 5.1, this fails with a NullPointerException (EJB is "SecuredBean" in "SecurityEJB.jar"):
> 21:02:02,890 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 21:02:02,890 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/C:/temp/jboss-5.1.0.GA/server/default/tmp/jsr88/Security.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying SecurityEJB.jar: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
> 	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:1210)
> 	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.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:413)
> 	at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.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 sun.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	at sun.reflect.GeneratedMethodAccessor304.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.GeneratedMethodAccessor303.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> 	at sun.rmi.transport.Transport$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
> 	... 68 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
> 	... 69 more
> I found that "<res-type>javax.ejb.SessionContext</res-type>" is missing. I think the deployment should raise a meaningful error message.
> I can provide you with a full sample if required.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:15:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 25 Jun 2009 15:15:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1856) NPE if
 "res-type" element is
 missing in ejb-jar.xml for injection of SessionContext
In-Reply-To: <8850904.1245957128139.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8221220.1245957356793.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1856:
--------------------------------------

    Assignee: jaikiran pai


> NPE if "res-type" element is missing in ejb-jar.xml for injection of SessionContext
> -----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1856
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1856
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.5
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>
> I have an ejb-jar.xml for an annotation free EJB. I try to inject a SessionContext.
> With JBoss 5.0, this snippet worked:
> 			<resource-ref>
> 				<res-ref-name>NameDoesNotCare</res-ref-name>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.some.package.SecuredBean</injection-target-class>
> 					<injection-target-name>mySessionContext</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> With JBoss 5.1, this fails with a NullPointerException (EJB is "SecuredBean" in "SecurityEJB.jar"):
> 21:02:02,890 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 21:02:02,890 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/C:/temp/jboss-5.1.0.GA/server/default/tmp/jsr88/Security.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying SecurityEJB.jar: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
> 	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:1210)
> 	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.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:413)
> 	at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.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 sun.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	at sun.reflect.GeneratedMethodAccessor304.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.GeneratedMethodAccessor303.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> 	at sun.rmi.transport.Transport$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
> 	... 68 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
> 	... 69 more
> I found that "<res-type>javax.ejb.SessionContext</res-type>" is missing. I think the deployment should raise a meaningful error message.
> I can provide you with a full sample if required.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:17:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 25 Jun 2009 15:17:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1856) NPE if
 "res-type" element is
 missing in ejb-jar.xml for injection of SessionContext
In-Reply-To: <8850904.1245957128139.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7479888.1245957477120.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1856:
-----------------------------------

    Component/s: core


> NPE if "res-type" element is missing in ejb-jar.xml for injection of SessionContext
> -----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1856
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1856
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>
> I have an ejb-jar.xml for an annotation free EJB. I try to inject a SessionContext.
> With JBoss 5.0, this snippet worked:
> 			<resource-ref>
> 				<res-ref-name>NameDoesNotCare</res-ref-name>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.some.package.SecuredBean</injection-target-class>
> 					<injection-target-name>mySessionContext</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> With JBoss 5.1, this fails with a NullPointerException (EJB is "SecuredBean" in "SecurityEJB.jar"):
> 21:02:02,890 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 21:02:02,890 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/C:/temp/jboss-5.1.0.GA/server/default/tmp/jsr88/Security.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying SecurityEJB.jar: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
> 	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:1210)
> 	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.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:413)
> 	at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.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 sun.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	at sun.reflect.GeneratedMethodAccessor304.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.GeneratedMethodAccessor303.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> 	at sun.rmi.transport.Transport$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
> 	... 68 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
> 	... 69 more
> I found that "<res-type>javax.ejb.SessionContext</res-type>" is missing. I think the deployment should raise a meaningful error message.
> I can provide you with a full sample if required.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:27:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Thu, 25 Jun 2009 15:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1856) NPE if
 "res-type" element
 is missing in ejb-jar.xml for injection of SessionContext
In-Reply-To: <8850904.1245957128139.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18959750.1245958076707.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473821#action_12473821 ] 

Wolfgang Knauf commented on EJBTHREE-1856:
------------------------------------------

You will find a working app here:
http://www.informatik.fh-wiesbaden.de/~knauf/KomponentenArchitekturen2008/security/SecurityNoAnnotation.ear
Simply remove the "res-type" line in ejb-jar.xml

I can modify it and attach it "broken" here if necessary, but this might take some days until I find the time ;-).

> NPE if "res-type" element is missing in ejb-jar.xml for injection of SessionContext
> -----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1856
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1856
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>
> I have an ejb-jar.xml for an annotation free EJB. I try to inject a SessionContext.
> With JBoss 5.0, this snippet worked:
> 			<resource-ref>
> 				<res-ref-name>NameDoesNotCare</res-ref-name>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.some.package.SecuredBean</injection-target-class>
> 					<injection-target-name>mySessionContext</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> With JBoss 5.1, this fails with a NullPointerException (EJB is "SecuredBean" in "SecurityEJB.jar"):
> 21:02:02,890 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 21:02:02,890 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/C:/temp/jboss-5.1.0.GA/server/default/tmp/jsr88/Security.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying SecurityEJB.jar: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
> 	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:1210)
> 	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.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:413)
> 	at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.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 sun.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	at sun.reflect.GeneratedMethodAccessor304.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.GeneratedMethodAccessor303.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> 	at sun.rmi.transport.Transport$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
> 	... 68 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
> 	... 69 more
> I found that "<res-type>javax.ejb.SessionContext</res-type>" is missing. I think the deployment should raise a meaningful error message.
> I can provide you with a full sample if required.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:29:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 25 Jun 2009 15:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2140) Function + MVEL
 dialect == rule firing in error
In-Reply-To: <7739511.1245894717244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24783117.1245958196561.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473822#action_12473822 ] 

Edson Tirelli commented on JBRULES-2140:
----------------------------------------

Ok, I found the problem. It was a classloader problem.

What happens is that generated types (like SomeBean in the example) are stored in the JavaDialectRuntimeData. 

When the package is added to a knowledgebase, the engine wires all types and classloaders to the respective classloaders used by the knowledgebase. So, the mvel consequence of the rule is wired against the java dialect classloader and everything works. 

Now, the presence of a function in the package forces a rewiring on the dialect data. Unfortunately, the re-wiring requires that a new classloader is created for the java dialect. By a hashcode coincidence, the re-wiring happens first on the mvel dialect and later on the java dialect. So, while the java dialect is using a new classloader, the mvel dialect was still referencing the old classloader. So the bean class in the mvel consequence was still using the old classloader, and not matching anything else in the rulebase.

Anyway, to fix this, since Java is our main dialect, I fixed the order of the rewiring to always be: java first, and then all other dialects.

I am running a full build now and will commit right after that.

Thanks for reporting and providing test case.

> Function + MVEL dialect == rule firing in error
> -----------------------------------------------
>
>                 Key: JBRULES-2140
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2140
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> REPORTED BY MICHAL:
> ---------------------------------------
> Hi,
> I've encountered a bizarre bug when a function is used together with a declared type and a rule with mvel dialect.
> To reproduce create a default 'New Drools Project' in Eclipse and replace Sample.drl with the following:
> --------------------------------------------------------------------------
> package com.sample
>  
> function void aaa() { // <----- comment this and it will work
> }
> declare SomeBean
> prop : int
> end
>  
> rule "setup"
> dialect "mvel"   // <----- comment this and it will work
> when
> eval(true)
> then
> SomeBean someBean = new SomeBean();
> insert(someBean);
> System.out.println( "setup inserted:" + someBean);
> end
> rule "should never fire"
> salience -20
> when
> not SomeBean()
> then
> System.out.println( "rule that should never fire fired !!!" );
> end
> ------------------------------------------------------------------------
> Run the DroolsTest.java and see that the last rule that should never fire is actually fired. If you comment out the 'aaa' function or change the dialect to 'java' all works fine.
> Note that it breaks on JDK 1.5.0_12 however it works fine on JDK 1.6.0_14.
> Tested on WinXP.
> Is it just my machine or does anybody else see this issue?
> Best regards,
> Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:34:09 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 25 Jun 2009 15:34:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2140) Function + MVEL
 dialect == rule firing in error
In-Reply-To: <7739511.1245894717244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7308320.1245958449171.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2140.
----------------------------------

    Resolution: Done


Fixed and committed to revision #27136.

Let me know if you still see any related problem.

Thanks,
Edson

> Function + MVEL dialect == rule firing in error
> -----------------------------------------------
>
>                 Key: JBRULES-2140
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2140
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> REPORTED BY MICHAL:
> ---------------------------------------
> Hi,
> I've encountered a bizarre bug when a function is used together with a declared type and a rule with mvel dialect.
> To reproduce create a default 'New Drools Project' in Eclipse and replace Sample.drl with the following:
> --------------------------------------------------------------------------
> package com.sample
>  
> function void aaa() { // <----- comment this and it will work
> }
> declare SomeBean
> prop : int
> end
>  
> rule "setup"
> dialect "mvel"   // <----- comment this and it will work
> when
> eval(true)
> then
> SomeBean someBean = new SomeBean();
> insert(someBean);
> System.out.println( "setup inserted:" + someBean);
> end
> rule "should never fire"
> salience -20
> when
> not SomeBean()
> then
> System.out.println( "rule that should never fire fired !!!" );
> end
> ------------------------------------------------------------------------
> Run the DroolsTest.java and see that the last rule that should never fire is actually fired. If you comment out the 'aaa' function or change the dialect to 'java' all works fine.
> Note that it breaks on JDK 1.5.0_12 however it works fine on JDK 1.6.0_14.
> Tested on WinXP.
> Is it just my machine or does anybody else see this issue?
> Best regards,
> Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:57:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 25 Jun 2009 15:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7056) Update to JBoss AOP
	2.1.3.GA
Message-ID: <4474870.1245959876452.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update to JBoss AOP 2.1.3.GA
----------------------------

                 Key: JBAS-7056
                 URL: https://jira.jboss.org/jira/browse/JBAS-7056
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Shelly McGowan
            Assignee: Shelly McGowan




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 16:02:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 25 Jun 2009 16:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7057) Update Kernel to
	2.0.8.GA
Message-ID: <28464517.1245960176528.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update Kernel to 2.0.8.GA
-------------------------

                 Key: JBAS-7057
                 URL: https://jira.jboss.org/jira/browse/JBAS-7057
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Shelly McGowan
            Assignee: Shelly McGowan




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:54:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 25 Jun 2009 05:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1851) Investigate the
 failure
 org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
In-Reply-To: <10648726.1245161216783.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7617255.1245923696741.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1851:
-----------------------------------

    Component/s: metrics-deployer


> Investigate the failure org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
> -------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1851
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1851
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: metrics-deployer, testsuite
>    Affects Versions: 1.1.7
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> The org.jboss.ejb3.test.container.unit.ContainerTestCase consistently fails with:
> javax.naming.NameNotFoundException: Stateful not bound
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
> 	at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
> 	at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> 	at java.lang.Thread.run(Thread.java:595)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> 	at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at org.jboss.ejb3.test.container.unit.ContainerTestCase.testInvocationStatistics(ContainerTestCase.java:93)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
> 	at junit.extensions.TestSetup.run(TestSetup.java:27)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:56:56 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Thu, 25 Jun 2009 05:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1642) Make the java
 ee example runnable on windows
In-Reply-To: <22235800.1244482856551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22559502.1245923816680.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1642.
------------------------------------

    Resolution: Done


> Make the java ee example runnable on windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-1642
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1642
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>         Attachments: build.xml
>
>
> The javaee examples are hard-coded for Linux (run.sh is used to start JBoss AS).
> For windows users, they have to manually edit the build files to sue run.bat instead.
> There is a note in the Beta1 release notes about that.
> The windows/linux difference should be parameterized so that the same build file
> could be used on both OSes.
> The windows file (*.bat) must also be checked to ensure they ends with  \r\n

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 17:28:56 2009
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Thu, 25 Jun 2009 17:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1000) COMPRESS corrupts
	some messages
In-Reply-To: <7560851.1245854756549.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2142637.1245965336591.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473830#action_12473830 ] 

Dennis Reed commented on JGRP-1000:
-----------------------------------

If I'm reading the RFCs and the compressed data correctly, the size of the compressed message is:

    ZLIB data: - 6 bytes (no DICTID)
    Compressed data - worst case is original size plus 5 bytes per 32K block

So the maximum buffer size needed would be something like: length + ( 5 * ( length / 32768 ) ) + 11
(the / is integer division)

References:
http://www.isi.edu/in-notes/rfc1950.txt
http://www.isi.edu/in-notes/rfc1951.txt

> COMPRESS corrupts some messages
> -------------------------------
>
>                 Key: JGRP-1000
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1000
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.5
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>
> COMPRESS.down() stores the compressed message in a temporary buffer the same size as the original message.
> If the compressed size of a message is larger than the original, then part of the message is lost, with no errors reported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 18:28:57 2009
From: jira-events at lists.jboss.org (Damon Horrell (JIRA))
Date: Thu, 25 Jun 2009 18:28:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2129) The
 WorkingMemoryEventListener doesn't set the oldObject for objectUpdated
 method.
In-Reply-To: <5650920.1245368156655.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5594939.1245968937376.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473837#action_12473837 ] 

Damon Horrell commented on JBRULES-2129:
----------------------------------------

This class is now called ObjectUpdatedEventImpl.  The bug still exists.

> The WorkingMemoryEventListener doesn't set the oldObject for objectUpdated method.
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2129
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2129
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.1.0.M1
>            Reporter: John Bebbington
>            Assignee: Mark Proctor
>
> The org.drools.event.rule.impl.ObjectEventImpl.java class has a fairly obvious error in it's constructor.
> The line:
>        object = event.getOldObject();
> Needs to be changed to:
>        oldObject = event.getOldObject();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 20:57:56 2009
From: jira-events at lists.jboss.org (murray armfield (JIRA))
Date: Thu, 25 Jun 2009 20:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6372) Add data source
 configuration files for Ingres RDBMS support
In-Reply-To: <3379588.1231456084356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28173076.1245977876915.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

murray armfield updated JBAS-6372:
----------------------------------

    Attachment: JBAS-ingres.tar.gz


Please disregard all previous file uploads. This is the current one to use.

> Add data source configuration files for Ingres RDBMS support
> ------------------------------------------------------------
>
>                 Key: JBAS-6372
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6372
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1, JBossAS-6.0.0.Alpha1, JBossAS-Branch_4_2
>         Environment: N/A
>            Reporter: murray armfield
>            Priority: Optional
>         Attachments: create_database.sql, create_database.sql, JBAS-ingres.tar.gz, jboss-soa-p.4.3.0.tar.gz
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> I'm working on getting JBoss going against the Ingres RDBMS database server. I've got some initial config files that can be included as part of the data source configurations. I have other patches for different components, but this issue is just to get two data source definitions added to the jbossas/trunk/connector/src/etc/example-config directory, one for a  local-tx-datasource and one for a xa-datasource.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 21:02:56 2009
From: jira-events at lists.jboss.org (murray armfield (JIRA))
Date: Thu, 25 Jun 2009 21:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6372) Add data source
 configuration files for Ingres RDBMS support
In-Reply-To: <3379588.1231456084356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17911441.1245978176502.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473841#action_12473841 ] 

murray armfield commented on JBAS-6372:
---------------------------------------

Hi Folks,
   I have been working around this for some time and have put together a better set of files for inclusion as JBoss AS.

   Please disregard all previous uploads except  JBAS-ingres.tar.gz. Although this is the most recent upload, it is not the last one in the list of downloads.

   In this tarball, there are the datasource templates for using Ingres and the messaging configuration file for Ingres. Additionally, Ingres use requires an updated CMP from what has been shipping in JBoss AS for some time now. I have included a copy of standardjbosscmp-jdbc.xml which has the current updated CMP for use with Ingres. Using this CMP means that all the other files that used to be part of this jIRA are no longer necessary.

    As an aside, the old download jboss-soa-p.4.3.0.tar.gz does have the ingres versions/files for what is distributed with JBoss SOA to make use of the automatic database reconfiguration scripts if your interested/can use them.

Take care,
    Murray

> Add data source configuration files for Ingres RDBMS support
> ------------------------------------------------------------
>
>                 Key: JBAS-6372
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6372
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1, JBossAS-6.0.0.Alpha1, JBossAS-Branch_4_2
>         Environment: N/A
>            Reporter: murray armfield
>            Priority: Optional
>         Attachments: create_database.sql, create_database.sql, JBAS-ingres.tar.gz, jboss-soa-p.4.3.0.tar.gz
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> I'm working on getting JBoss going against the Ingres RDBMS database server. I've got some initial config files that can be included as part of the data source configurations. I have other patches for different components, but this issue is just to get two data source definitions added to the jbossas/trunk/connector/src/etc/example-config directory, one for a  local-tx-datasource and one for a xa-datasource.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 21:39:56 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Thu, 25 Jun 2009 21:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1667) MBeans
 cannot have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31994.1245980396701.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473842#action_12473842 ] 

Richard Kennard commented on JBMESSAGING-1667:
----------------------------------------------

Fair enough, I will use dots.

Many thanks for spending time discussing and looking into this issue for me.

Regards,

Richard.

> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 22:47:56 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 25 Jun 2009 22:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2143) marshalling of
 facthandle as externalForm
Message-ID: <2548603.1245984476473.JavaMail.jira@cloud.prod.atl2.jboss.com>

marshalling of facthandle as externalForm
-----------------------------------------

                 Key: JBRULES-2143
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2143
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Michael Neale
            Assignee: Michael Neale
             Fix For: 5.1.0.M1


Don't need to unmarshal, but would be nice to marshal fact handles as <fact-handle externalForm=...>

Needed for the advisor/smart forms thing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 22:51:56 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 25 Jun 2009 22:51:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2143) marshalling of
 facthandle as externalForm
In-Reply-To: <2548603.1245984476473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8512767.1245984716468.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Neale closed JBRULES-2143.
----------------------------------

    Resolution: Done


> marshalling of facthandle as externalForm
> -----------------------------------------
>
>                 Key: JBRULES-2143
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2143
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Michael Neale
>            Assignee: Michael Neale
>             Fix For: 5.1.0.M1
>
>
> Don't need to unmarshal, but would be nice to marshal fact handles as <fact-handle externalForm=...>
> Needed for the advisor/smart forms thing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 23:07:56 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 25 Jun 2009 23:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2129) The
 WorkingMemoryEventListener doesn't set the oldObject for objectUpdated
 method.
In-Reply-To: <5650920.1245368156655.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12436024.1245985676940.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Neale reassigned JBRULES-2129:
--------------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)


> The WorkingMemoryEventListener doesn't set the oldObject for objectUpdated method.
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2129
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2129
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.1.0.M1
>            Reporter: John Bebbington
>            Assignee: Michael Neale
>
> The org.drools.event.rule.impl.ObjectEventImpl.java class has a fairly obvious error in it's constructor.
> The line:
>        object = event.getOldObject();
> Needs to be changed to:
>        oldObject = event.getOldObject();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 23:09:59 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 25 Jun 2009 23:09:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2129) The
 WorkingMemoryEventListener
 doesn't set the oldObject for objectUpdated method.
In-Reply-To: <5650920.1245368156655.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6259606.1245985799351.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Neale closed JBRULES-2129.
----------------------------------

    Fix Version/s: 5.1.0.M1
       Resolution: Done


> The WorkingMemoryEventListener doesn't set the oldObject for objectUpdated method.
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2129
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2129
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.1.0.M1
>            Reporter: John Bebbington
>            Assignee: Michael Neale
>             Fix For: 5.1.0.M1
>
>
> The org.drools.event.rule.impl.ObjectEventImpl.java class has a fairly obvious error in it's constructor.
> The line:
>        object = event.getOldObject();
> Needs to be changed to:
>        oldObject = event.getOldObject();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 01:50:56 2009
From: jira-events at lists.jboss.org (Mladen Turk (JIRA))
Date: Fri, 26 Jun 2009 01:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4558) Connection Timeout
 Immediately After ACKing A Request
In-Reply-To: <29886208.1184706647200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25060641.1245995456784.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mladen Turk closed JBAS-4558.
-----------------------------

    Resolution: Out of Date


Cleanup

> Connection Timeout Immediately After ACKing A Request
> -----------------------------------------------------
>
>                 Key: JBAS-4558
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4558
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Mike Millson
>            Assignee: Mladen Turk
>         Attachments: drop5.cap
>
>
> The customer has an application that periodically sends Web service requests to JBoss AS every 20 secs in sets of 4, to check wether the Web Service is up. They find that JBoss AS occasionally drops the request packets when the HTTP connector timeout is set to 20 seconds. When this happens, the packet sequence is very strange. Attached is an example packet sequence viewable using ethereal/WireShark.
> #275: Client sends request >20 seconds after #274 acknowledgment
> #276: Server sends ACK for #275
> #277: Server sends connection timeout FIN/ACK
> #278 Client sends combined ACK for #277 and FIN/ACK
> #279 Server sends ACK for #278
> Packet #275 was more than 20 seconds after the last packet was sent; however, it was received before the server initiated the connection timeout sequence in packets #277-279. It seems to be unaware of the ACK in #276. Almost as if the timeout sequence started, then before the FIN/ACK could be sent, another packet was received and acknowledged. Some sort of timing issue when a request is sent at the same time a connection times out. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 02:52:56 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 26 Jun 2009 02:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JASSIST-79) Editing
 MethodCall produces
 incorrect byte code | java.lang.VerifyError: Illegal target of jump or
 branch | goto points to invalid instruction
In-Reply-To: <25834444.1239876805355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29860397.1245999176724.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JASSIST-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473871#action_12473871 ] 

Shigeru Chiba commented on JASSIST-79:
--------------------------------------

I fixed this problem (it took long time :-0) and the fix is now in the CVS head.  This fix will be included in the upcoming release 3.11.

> Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | goto points to invalid instruction
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-79
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-79
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>         Environment: $ java -version
> java version "1.6.0_07"
> Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
> Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)
>            Reporter: Martin Burger
>            Assignee: Shigeru Chiba
>         Attachments: jinsi-jassist-79.tgz, Parser.instrumented.class, Parser.instrumented.dump, Parser.original.class, Parser.original.dump, Parser.original.jad, Parser.original.java
>
>
> I instrument method calls in a class called org.mozilla.javascript.Parser.
> If I run (or, load) this class, a java.lang.VerifyError will be thrown:
> Exception in thread "main" java.lang.VerifyError: (class: org/mozilla/javascript/Parser, method: statementHelper signature: (Lorg/mozilla/javascript/TokenStream;)Ljava/lang/Object;) Illegal target of jump or branch
> It seems Javassist introduces a defective goto statement at position 3200 in method statementHelper:
> 3200:        goto    -29495
> Obviously, offset -29495 is an invalid opcode address.
> The corresponding Java code (excerpt):
>         switch(tt) {
>         case TokenStream.IF: {
>             skipsemi = true;
>             sourceAdd((char)ts.IF);
>             int lineno = ts.getLineno();
>             Object cond = condition(ts);
>             sourceAdd((char)ts.LC);
>             sourceAdd((char)ts.EOL);
>             Object ifTrue = statement(ts);
>             Object ifFalse = null;
>             if (ts.matchToken(ts.ELSE)) {
>                 sourceAdd((char)ts.RC);
>                 sourceAdd((char)ts.ELSE);
>                 sourceAdd((char)ts.LC);
>                 sourceAdd((char)ts.EOL);
>                 ifFalse = statement(ts);
>             }
>             sourceAdd((char)ts.RC);
>             sourceAdd((char)ts.EOL);
>             pn = nf.createIf(cond, ifTrue, ifFalse, lineno);
>             break;
>         }
>         case TokenStream.SWITCH: {
> I think the break statement is related to this defect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 02:54:56 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 26 Jun 2009 02:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-80) Editing MethodCall
 produces
 incorrect byte code | java.lang.VerifyError: Illegal target of jump or
 branch | invalid instruction
In-Reply-To: <24108261.1239967464758.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5013090.1245999296586.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-80.
----------------------------------

       Resolution: Done
    Fix Version/s: 3.11.0.GA


See JASSIST-79

> Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | invalid instruction
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-80
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-80
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>         Environment: $ java -version
> java version "1.6.0_07"
> Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
> Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode) 
>            Reporter: Martin Burger
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>         Attachments: TokenStream.java, TokenStream_instrumented.class, TokenStream_instrumented.dump, TokenStream_original.class
>
>
> Note: Most likely this issue is related to JASSIST-79.
> I instrument method calls in a class called org.mozilla.javascript.TokenStream.
> If I run (or, load) this class, a java.lang.VerifyError will be thrown:
> Exception in thread "main" java.lang.VerifyError: (class: org/mozilla/javascript/TokenStream, method: getToken$JINSI_4etOXffNDXVw signature: ()I) Illegal target of jump or branch
> It seems Javassist introduces a defective goto statement at position 33217 in method getToken$JINSI_4etOXffNDXVw:
> 33217	goto	465
> The corresponding Java code (excerpt):
>             case '-':
>                 if (matchChar('=')) {
>                     this.op = SUB;
>                     c = ASSIGN;
>                 } else if (matchChar('-')) {
>                     if (0 == (flags & TSF_DIRTYLINE)) {
>                         // treat HTML end-comment after possible whitespace
>                         // after line start as comment-utill-eol
>                         if (matchChar('>')) {
>                             skipLine();
>                             continue retry;
>                         }
>                     }
>                     c = DEC;
>                 } else {
>                     c = SUB;
>                 }
>                 flags |= TSF_DIRTYLINE;
>                 return c;
> I think the continue statement is related to this defect.
> JAD fails to decompile the instrumented class:
> ERROR: invalid instruction at 33217 in the method getToken$JINSI_4etOXffNDXVw. The method will be decompiled incorrectly.
> Javassist's framedump fails, too:
> Exception in thread "main" java.lang.RuntimeException: javassist.bytecode.BadBytecode: Stack is empty[pos = 465]
>         at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:89)
>         at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:60)
>         at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:51)
>         at javassist.tools.framedump.main(framedump.java:45)
> Caused by: javassist.bytecode.BadBytecode: Stack is empty[pos = 465]
>         at javassist.bytecode.analysis.Analyzer.analyzeNextEntry(Analyzer.java:179)
>         at javassist.bytecode.analysis.Analyzer.analyze(Analyzer.java:143)
>         at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:87)
>         ... 3 more
> Caused by: java.lang.IndexOutOfBoundsException: Stack is empty
>         at javassist.bytecode.analysis.Frame.pop(Frame.java:130)
>         at javassist.bytecode.analysis.Executor.simplePop(Executor.java:970)
>         at javassist.bytecode.analysis.Executor.evalStore(Executor.java:869)
>         at javassist.bytecode.analysis.Executor.execute(Executor.java:188)
>         at javassist.bytecode.analysis.Analyzer.analyzeNextEntry(Analyzer.java:177)
>         ... 5 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 02:56:56 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 26 Jun 2009 02:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-79) Editing MethodCall
 produces
 incorrect byte code | java.lang.VerifyError: Illegal target of jump or
 branch | goto points to invalid instruction
In-Reply-To: <25834444.1239876805355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32026912.1245999416463.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-79.
----------------------------------

       Resolution: Done
    Fix Version/s: 3.11.0.GA


> Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | goto points to invalid instruction
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-79
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-79
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>         Environment: $ java -version
> java version "1.6.0_07"
> Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
> Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)
>            Reporter: Martin Burger
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>         Attachments: jinsi-jassist-79.tgz, Parser.instrumented.class, Parser.instrumented.dump, Parser.original.class, Parser.original.dump, Parser.original.jad, Parser.original.java
>
>
> I instrument method calls in a class called org.mozilla.javascript.Parser.
> If I run (or, load) this class, a java.lang.VerifyError will be thrown:
> Exception in thread "main" java.lang.VerifyError: (class: org/mozilla/javascript/Parser, method: statementHelper signature: (Lorg/mozilla/javascript/TokenStream;)Ljava/lang/Object;) Illegal target of jump or branch
> It seems Javassist introduces a defective goto statement at position 3200 in method statementHelper:
> 3200:        goto    -29495
> Obviously, offset -29495 is an invalid opcode address.
> The corresponding Java code (excerpt):
>         switch(tt) {
>         case TokenStream.IF: {
>             skipsemi = true;
>             sourceAdd((char)ts.IF);
>             int lineno = ts.getLineno();
>             Object cond = condition(ts);
>             sourceAdd((char)ts.LC);
>             sourceAdd((char)ts.EOL);
>             Object ifTrue = statement(ts);
>             Object ifFalse = null;
>             if (ts.matchToken(ts.ELSE)) {
>                 sourceAdd((char)ts.RC);
>                 sourceAdd((char)ts.ELSE);
>                 sourceAdd((char)ts.LC);
>                 sourceAdd((char)ts.EOL);
>                 ifFalse = statement(ts);
>             }
>             sourceAdd((char)ts.RC);
>             sourceAdd((char)ts.EOL);
>             pn = nf.createIf(cond, ifTrue, ifFalse, lineno);
>             break;
>         }
>         case TokenStream.SWITCH: {
> I think the break statement is related to this defect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 03:07:56 2009
From: jira-events at lists.jboss.org (Salvatore Di Franca (JIRA))
Date: Fri, 26 Jun 2009 03:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7058) JBOSS: HEAP MEMROY
	USAGE
Message-ID: <26729176.1246000076871.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBOSS: HEAP MEMROY USAGE
------------------------

                 Key: JBAS-7058
                 URL: https://jira.jboss.org/jira/browse/JBAS-7058
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: System service
    Affects Versions: JBossAS-5.1.0.GA
         Environment: OS Ubuntu 8.04 kernel 2.6.24
JVM 1.6_14
CPU: Intel Core 2 duo 3.00 GHZ E8400
            Reporter: Salvatore Di Franca
            Assignee: Dimitris Andreadis


When i start the Jboss application server the  percentage of heap used splashes 99% how you see follows:.

{Heap before GC invocations=142 (full 1):
 PSYoungGen      total 56832K, used 55472K [0xb07d0000, 0xb40b0000, 0xb40b0000)
  eden space 55360K, 100% used [0xb07d0000,0xb3de0000,0xb3de0000)
  from space 1472K, 7% used [0xb3f40000,0xb3f5c000,0xb40b0000)
  to   space 1408K, 0% used [0xb3de0000,0xb3de0000,0xb3f40000)
 PSOldGen        total 466048K, used 198091K [0x940b0000, 0xb07d0000, 0xb07d0000)
  object space 466048K, 42% used [0x940b0000,0xa0222d38,0xb07d0000)
 PSPermGen       total 64384K, used 64371K [0x740b0000, 0x77f90000, 0x940b0000)
  object space 64384K, 99% used [0x740b0000,0x77f8ce08,0x77f90000)
Heap after GC invocations=142 (full 1):
 PSYoungGen      total 56768K, used 144K [0xb07d0000, 0xb40b0000, 0xb40b0000)
  eden space 55360K, 0% used [0xb07d0000,0xb07d0000,0xb3de0000)
  from space 1408K, 10% used [0xb3de0000,0xb3e04000,0xb3f40000)
  to   space 1280K, 0% used [0xb3f70000,0xb3f70000,0xb40b0000)
 PSOldGen        total 466048K, used 198091K [0x940b0000, 0xb07d0000, 0xb07d0000)
  object space 466048K, 42% used [0x940b0000,0xa0222d38,0xb07d0000)
 PSPermGen       total 64384K, used 64371K [0x740b0000, 0x77f90000, 0x940b0000)
  object space 64384K, 99% used [0x740b0000,0x77f8ce08,0x77f90000)
}


I am starting jboss with the following jvm params; -Xms512m -Xmx512m -XX:MaxPermSize=512M -XX:+PrintHeapAtGC



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 03:09:56 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 26 Jun 2009 03:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-85) IllegalAccessError
 when trying to call clone() on a class generated by ProxyFactory
In-Reply-To: <15165406.1245755876804.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21229795.1246000196737.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-85.
----------------------------------

    Fix Version/s: 3.11.0.GA
       Resolution: Done


I applied the patch.  Thanks!

> IllegalAccessError when trying to call clone() on a class generated by ProxyFactory
> -----------------------------------------------------------------------------------
>
>                 Key: JASSIST-85
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-85
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>            Reporter: Tobias Meyer
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>
> Hibernate 3.3 uses javassist (by default) to generate LazyInitializer Objects.
> If a lazily loaded object implements the clone() method, and makes it public, there will be a runtime IllegalAccessError because the javassist proxy object exports the protected definition of Object.clone() instead of the definition in the MethodHandler's Interface.
> The supplied patch makes the ProxyFactory to never reduce the visibility of a public method, even if implemented in a higher interface or the superclass.
> Normally the java compiler would catch such an error, so this is assumed to be save.
> Side effect is of course that a superclass method given to ProxyFactory might not be called as before because a public definition of the MethodHandler (Interface) overloads it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 03:22:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 26 Jun 2009 03:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1857) Track the
 upgrades during EJB3 plugin 1.0.10 release
Message-ID: <11399327.1246000976433.JavaMail.jira@cloud.prod.atl2.jboss.com>

Track the upgrades during EJB3 plugin 1.0.10 release
----------------------------------------------------

                 Key: EJBTHREE-1857
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1857
             Project: EJB 3.0
          Issue Type: Task
          Components: plugin
            Reporter: jaikiran pai
            Assignee: jaikiran pai


This issue is to track any updates to version dependencies during the EJB3 1.0.10 plugin release.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 03:45:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 26 Jun 2009 03:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19234099.1246002356568.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated JBDEPLOY-201:
------------------------------------

    Comment: was deleted


> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Ales Justin
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 04:03:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 26 Jun 2009 04:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1856) NPE if
 "res-type" element is
 missing in ejb-jar.xml for injection of SessionContext
In-Reply-To: <8850904.1245957128139.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18251582.1246003436494.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1856.
------------------------------------

    Resolution: Duplicate Issue


Turns out to be the same issue as this one https://jira.jboss.org/jira/browse/EJBTHREE-1823. Could you please use our EJB3 plugin http://www.jboss.org/ejb3/ejb3plugin.html to upgrade to that version or even our latest version? The released versions of the plugin are available here http://www.jboss.org/ejb3/downloads.html

> NPE if "res-type" element is missing in ejb-jar.xml for injection of SessionContext
> -----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1856
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1856
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>
> I have an ejb-jar.xml for an annotation free EJB. I try to inject a SessionContext.
> With JBoss 5.0, this snippet worked:
> 			<resource-ref>
> 				<res-ref-name>NameDoesNotCare</res-ref-name>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.some.package.SecuredBean</injection-target-class>
> 					<injection-target-name>mySessionContext</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> With JBoss 5.1, this fails with a NullPointerException (EJB is "SecuredBean" in "SecurityEJB.jar"):
> 21:02:02,890 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 21:02:02,890 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/C:/temp/jboss-5.1.0.GA/server/default/tmp/jsr88/Security.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying SecurityEJB.jar: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
> 	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:1210)
> 	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.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:413)
> 	at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.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 sun.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	at sun.reflect.GeneratedMethodAccessor304.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.GeneratedMethodAccessor303.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> 	at sun.rmi.transport.Transport$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
> 	... 68 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
> 	... 69 more
> I found that "<res-type>javax.ejb.SessionContext</res-type>" is missing. I think the deployment should raise a meaningful error message.
> I can provide you with a full sample if required.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 05:08:08 2009
From: jira-events at lists.jboss.org (Bulat Nigmatullin (JIRA))
Date: Fri, 26 Jun 2009 05:08:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Admin Join problem
 -GMS flush by coordinator failed
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15203353.1246007288144.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473892#action_12473892 ] 

Bulat Nigmatullin commented on JGRP-985:
----------------------------------------

I have the same issue with 2.8.0 Beta1. This is the logs of two servers (dont pay attention to log timestamps, there is a small misconception with server datetimes):

Joining server: 

2009.06.26 13:03:17 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:03:24 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:03:31 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:03:38 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:03:45 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:03:52 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:03:59 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:04:06 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:04:13 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:04:20 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:04:27 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying

Coordinator server:

2009.06.26 13:10:32 jabber02.rambler.ru-42629: GMS flush by coordinator failed
2009.06.26 13:10:47 jabber02.rambler.ru-42629: GMS flush by coordinator failed
2009.06.26 13:11:03 jabber02.rambler.ru-42629: GMS flush by coordinator failed
2009.06.26 13:11:20 jabber02.rambler.ru-42629: GMS flush by coordinator failed
2009.06.26 13:11:35 jabber02.rambler.ru-42629: GMS flush by coordinator failed
2009.06.26 13:11:37 jabber02.rambler.ru-42629: failed to collect all ACKs (expected=5) for view [jabber02.rambler.ru-42629|38] [jabber02.rambler.ru-42629, jabber15.rambler.ru-14938, jabber16.rambler.ru-24876, jabber17.rambler.ru-30400, jabber01.rambler.ru-48589, jabber01.rambler.ru-50481] after 2000ms, missing ACKs from [jabber15.rambler.ru-14938, jabber01.rambler.ru-48589] (received=[jabber17.rambler.ru-30400, jabber16.rambler.ru-24876, jabber02.rambler.ru-42629])
2009.06.26 13:12:58 jabber02.rambler.ru-42629: GMS flush by coordinator failed
2009.06.26 13:13:00 jabber02.rambler.ru-42629: failed to collect all ACKs (expected=5) for view [jabber02.rambler.ru-42629|39] [jabber02.rambler.ru-42629, jabber15.rambler.ru-14938, jabber16.rambler.ru-24876, jabber17.rambler.ru-30400, jabber01.rambler.ru-50481] after 2000ms, missing ACKs from [jabber15.rambler.ru-14938] (received=[jabber17.rambler.ru-30400, jabber16.rambler.ru-24876, jabber02.rambler.ru-42629, jabber01.rambler.ru-50481])

After two minutes from joining server start GMS was OK, but other flushes was broken:

Joining server:

2009.06.26 13:12:08 Flush failed at jabber01.rambler.ru-50481:Sessions by Hostname
2009.06.26 13:12:10 failed to collect all service ACKs (5) for [dst: <null>, src: jabber01.rambler.ru-50481 (4 headers), size=0 bytes] after 2000ms, missing ACKs from [jabber15.rambler.ru-14938] (received=[jabber17.rambler.ru-30400, jabber16.rambler.ru-24876, jabber02.rambler.ru-42629, jabber01.rambler.ru-50481]), local_addr=jabber01.rambler.ru-50481
2009.06.26 13:12:36 Flush failed at jabber01.rambler.ru-50481:Remote Users Existence
2009.06.26 13:12:38 failed to collect all service ACKs (5) for [dst: <null>, src: jabber01.rambler.ru-50481 (4 headers), size=0 bytes] after 2000ms, missing ACKs from [jabber15.rambler.ru-14938] (received=[jabber17.rambler.ru-30400, jabber16.rambler.ru-24876, jabber02.rambler.ru-42629, jabber01.rambler.ru-50481]), local_addr=jabber01.rambler.ru-50481


Member server:

2009.06.26 13:06:34 jabber15.rambler.ru-14938: discarded message from non-member jabber01.rambler.ru-50481, my view is [jabber02.rambler.ru-42629|17] [jabber02.rambler.ru-42629, jabber15.rambler.ru-14938, jabber16.rambler.ru-24876, jabber17.rambler.ru-30400]
2009.06.26 13:06:43 jabber15.rambler.ru-14938: discarded message from non-member jabber01.rambler.ru-50481, my view is [jabber02.rambler.ru-42629|17] [jabber02.rambler.ru-42629, jabber15.rambler.ru-14938, jabber16.rambler.ru-24876, jabber17.rambler.ru-30400]
2009.06.26 13:07:01 jabber15.rambler.ru-14938: discarded message from non-member jabber01.rambler.ru-50481, my view is [jabber02.rambler.ru-42629|17] [jabber02.rambler.ru-42629, jabber15.rambler.ru-14938, jabber16.rambler.ru-24876, jabber17.rambler.ru-30400]
2009.06.26 13:07:03 jabber15.rambler.ru-14938: discarded message from non-member jabber01.rambler.ru-50481, my view is [jabber02.rambler.ru-42629|17] [jabber02.rambler.ru-42629, jabber15.rambler.ru-14938, jabber16.rambler.ru-24876, jabber17.rambler.ru-30400]
2009.06.26 13:07:03 jabber15.rambler.ru-14938: discarded message from non-member jabber01.rambler.ru-50481, my view is [jabber02.rambler.ru-42629|17] [jabber02.rambler.ru-42629, jabber15.rambler.ru-14938, jabber16.rambler.ru-24876, jabber17.rambler.ru-30400]



> Admin  Join problem -GMS flush by coordinator failed
> ----------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 05:30:08 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 05:30:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-984) JGroups can not
 parse IPV6 literals in TCPPING protocol configuration
In-Reply-To: <7188979.1242741125294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1579206.1246008608567.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473896#action_12473896 ] 

Bela Ban commented on JGRP-984:
-------------------------------

I tried this with 2.4 branch and CVS head (2.8) and in both cases, this worked fine for me. Can you paste a stack trace, and your entire config file ?

> JGroups can not parse IPV6 literals in TCPPING protocol configuration
> ---------------------------------------------------------------------
>
>                 Key: JGRP-984
>                 URL: https://jira.jboss.org/jira/browse/JGRP-984
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.6
>            Reporter: Brian Stansberry
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> ON JBPAPP-2013 Dominik Pospisil reports the IPv6 address parsing fix in 2.4.6 doesn't handle TCPPING:
> Both
> <TCPPING initial_hosts="::1[7810],fec0::f101:21a:a0ff:fea0:d745[7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> and
> <TCPPING initial_hosts="[::1][7810],[fec0::f101:21a:a0ff:fea0:d745][7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> fails with:
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "::1"
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "fec0::f101:21a:a0ff:fea0:d745"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 05:38:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 05:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-957) Intermittent
 cluster stability issues
In-Reply-To: <4862356.1239785615454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30018012.1246009136503.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473897#action_12473897 ] 

Bela Ban commented on JGRP-957:
-------------------------------

2.7 is not a supported version, use either 2.6.x or 2.8 and resubmit if the problem still occurs

> Intermittent cluster stability issues
> -------------------------------------
>
>                 Key: JGRP-957
>                 URL: https://jira.jboss.org/jira/browse/JGRP-957
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: jdk 1.5
>            Reporter: a C
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: jgroups-logs.zip
>
>
> We are using jgroups as a notification system between webapps running inside tomcat or weblogic server. In our current test platform all cluster nodes are on the same host, most of them on the same container (tomcat). Some web-applictions may have several connections to the cluster.
> We use UDP multicast on a LAN, the configuration is nearly the default one.
> The system seems to work fine but regularly  we have cluster stability issues. Typically lot of SUSPECT messages are exchanged, a lot of "GMS: address ..."  items are logged on standard output, the number of view accepted events dramatically increases.
> As an example, looking at the number of  viewaccepted (grep -c viewAccepted */logout.log):
> logout.log.2009-03-25:6
> logout.log.2009-03-26:51
> logout.log.2009-03-27:49
> logout.log.2009-03-28:0
> logout.log.2009-03-29:2290
> logout.log.2009-03-30:64
> logout.log.2009-03-31:55
> logout.log.2009-04-01:15
> logout.log.2009-04-02:433
> logout.log.2009-04-03:32
> logout.log.2009-04-04:4
> logout.log.2009-04-05:5
> logout.log.2009-04-06:38
> logout.log.2009-04-07:26
> logout.log.2009-04-08:30
> logout.log.2009-04-09:19
> logout.log.2009-04-10:32
> logout.log.2009-04-11:5
> logout.log.2009-04-12:7
> logout.log.2009-04-13:2236
> logout.log.2009-04-14:56
> We performed several test campaigns sending and receiving messages during a 2 or 3 dyas period and checking for message loss but everything went right. Until the problems appears again. No network issue was detected by our system administrator.
> Another typical problem is that members send NOT_MEMBER messages causing stacks to shutdown (should I say channels to close?). [ Received NOT_MEMBER event from null I'm being shunned; exiting]. The shun option is not set (neither Channel with auto-reconnect option set) and nevertheless in some cases the stack starts up again (CloserThread - reconnecting to group ...)and in other cases not. Please note that when the stack does not start up automatically, it is impossible to connect to the channel manually (we always receive ChannelClosedException)
> Typically
> [sip at bipro tmusadmin]$ grep -c NOT_MEMBER jgroup.log*
> jgroup.log:0
> jgroup.log.2009-03-30:3
> jgroup.log.2009-03-31:0
> jgroup.log.2009-04-01:0
> jgroup.log.2009-04-02:1370
> jgroup.log.2009-04-07:0
> jgroup.log.2009-04-10:0
> jgroup.log.2009-04-11:11
> jgroup.log.2009-04-12:9
> jgroup.log.2009-04-13:587
> jgroup.log.2009-04-14:0
> A suggestion would be greatly appreciated.
> Sory for the size of the logs!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 05:41:08 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 05:41:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-957) Intermittent
 cluster stability issues
In-Reply-To: <4862356.1239785615454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29955804.1246009268166.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473898#action_12473898 ] 

Bela Ban commented on JGRP-957:
-------------------------------

Note that NOT_MEMBER and shunning has been removed from the 2.8 (currently beta2) release, so this issue should not occur anymore.

> Intermittent cluster stability issues
> -------------------------------------
>
>                 Key: JGRP-957
>                 URL: https://jira.jboss.org/jira/browse/JGRP-957
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: jdk 1.5
>            Reporter: a C
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: jgroups-logs.zip
>
>
> We are using jgroups as a notification system between webapps running inside tomcat or weblogic server. In our current test platform all cluster nodes are on the same host, most of them on the same container (tomcat). Some web-applictions may have several connections to the cluster.
> We use UDP multicast on a LAN, the configuration is nearly the default one.
> The system seems to work fine but regularly  we have cluster stability issues. Typically lot of SUSPECT messages are exchanged, a lot of "GMS: address ..."  items are logged on standard output, the number of view accepted events dramatically increases.
> As an example, looking at the number of  viewaccepted (grep -c viewAccepted */logout.log):
> logout.log.2009-03-25:6
> logout.log.2009-03-26:51
> logout.log.2009-03-27:49
> logout.log.2009-03-28:0
> logout.log.2009-03-29:2290
> logout.log.2009-03-30:64
> logout.log.2009-03-31:55
> logout.log.2009-04-01:15
> logout.log.2009-04-02:433
> logout.log.2009-04-03:32
> logout.log.2009-04-04:4
> logout.log.2009-04-05:5
> logout.log.2009-04-06:38
> logout.log.2009-04-07:26
> logout.log.2009-04-08:30
> logout.log.2009-04-09:19
> logout.log.2009-04-10:32
> logout.log.2009-04-11:5
> logout.log.2009-04-12:7
> logout.log.2009-04-13:2236
> logout.log.2009-04-14:56
> We performed several test campaigns sending and receiving messages during a 2 or 3 dyas period and checking for message loss but everything went right. Until the problems appears again. No network issue was detected by our system administrator.
> Another typical problem is that members send NOT_MEMBER messages causing stacks to shutdown (should I say channels to close?). [ Received NOT_MEMBER event from null I'm being shunned; exiting]. The shun option is not set (neither Channel with auto-reconnect option set) and nevertheless in some cases the stack starts up again (CloserThread - reconnecting to group ...)and in other cases not. Please note that when the stack does not start up automatically, it is impossible to connect to the channel manually (we always receive ChannelClosedException)
> Typically
> [sip at bipro tmusadmin]$ grep -c NOT_MEMBER jgroup.log*
> jgroup.log:0
> jgroup.log.2009-03-30:3
> jgroup.log.2009-03-31:0
> jgroup.log.2009-04-01:0
> jgroup.log.2009-04-02:1370
> jgroup.log.2009-04-07:0
> jgroup.log.2009-04-10:0
> jgroup.log.2009-04-11:11
> jgroup.log.2009-04-12:9
> jgroup.log.2009-04-13:587
> jgroup.log.2009-04-14:0
> A suggestion would be greatly appreciated.
> Sory for the size of the logs!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 05:41:08 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 05:41:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-957) Intermittent cluster
 stability issues
In-Reply-To: <4862356.1239785615454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21207894.1246009268341.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban closed JGRP-957.
-------------------------

    Resolution: Out of Date


2.7 is not a supported version

> Intermittent cluster stability issues
> -------------------------------------
>
>                 Key: JGRP-957
>                 URL: https://jira.jboss.org/jira/browse/JGRP-957
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: jdk 1.5
>            Reporter: a C
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: jgroups-logs.zip
>
>
> We are using jgroups as a notification system between webapps running inside tomcat or weblogic server. In our current test platform all cluster nodes are on the same host, most of them on the same container (tomcat). Some web-applictions may have several connections to the cluster.
> We use UDP multicast on a LAN, the configuration is nearly the default one.
> The system seems to work fine but regularly  we have cluster stability issues. Typically lot of SUSPECT messages are exchanged, a lot of "GMS: address ..."  items are logged on standard output, the number of view accepted events dramatically increases.
> As an example, looking at the number of  viewaccepted (grep -c viewAccepted */logout.log):
> logout.log.2009-03-25:6
> logout.log.2009-03-26:51
> logout.log.2009-03-27:49
> logout.log.2009-03-28:0
> logout.log.2009-03-29:2290
> logout.log.2009-03-30:64
> logout.log.2009-03-31:55
> logout.log.2009-04-01:15
> logout.log.2009-04-02:433
> logout.log.2009-04-03:32
> logout.log.2009-04-04:4
> logout.log.2009-04-05:5
> logout.log.2009-04-06:38
> logout.log.2009-04-07:26
> logout.log.2009-04-08:30
> logout.log.2009-04-09:19
> logout.log.2009-04-10:32
> logout.log.2009-04-11:5
> logout.log.2009-04-12:7
> logout.log.2009-04-13:2236
> logout.log.2009-04-14:56
> We performed several test campaigns sending and receiving messages during a 2 or 3 dyas period and checking for message loss but everything went right. Until the problems appears again. No network issue was detected by our system administrator.
> Another typical problem is that members send NOT_MEMBER messages causing stacks to shutdown (should I say channels to close?). [ Received NOT_MEMBER event from null I'm being shunned; exiting]. The shun option is not set (neither Channel with auto-reconnect option set) and nevertheless in some cases the stack starts up again (CloserThread - reconnecting to group ...)and in other cases not. Please note that when the stack does not start up automatically, it is impossible to connect to the channel manually (we always receive ChannelClosedException)
> Typically
> [sip at bipro tmusadmin]$ grep -c NOT_MEMBER jgroup.log*
> jgroup.log:0
> jgroup.log.2009-03-30:3
> jgroup.log.2009-03-31:0
> jgroup.log.2009-04-01:0
> jgroup.log.2009-04-02:1370
> jgroup.log.2009-04-07:0
> jgroup.log.2009-04-10:0
> jgroup.log.2009-04-11:11
> jgroup.log.2009-04-12:9
> jgroup.log.2009-04-13:587
> jgroup.log.2009-04-14:0
> A suggestion would be greatly appreciated.
> Sory for the size of the logs!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 05:58:57 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Fri, 26 Jun 2009 05:58:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1003) deadlock in TP.send
 - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
Message-ID: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>

deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
------------------------------------------------------------------------------------------------

                 Key: JGRP-1003
                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.7
         Environment: Linux (Debian), kernel 2.6.x
            Reporter: Victor N
            Assignee: Bela Ban


I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).

Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.


1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":

"Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
   java.lang.Thread.State: RUNNABLE                                                                                                                                              
        at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
        at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
        at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
        - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
        at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
        at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
        at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
        at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
        at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
        at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
        at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
        at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
        at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
        at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
        at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
        at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
        at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
        at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
        at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
        at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
        at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
        at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
        at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
        at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
        at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
        at java.lang.Thread.run(Thread.java:619)

   Locked ownable synchronizers:                                                                                                                                                 
        - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
        - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
        - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)


2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:

"Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
   java.lang.Thread.State: WAITING (parking)                                                                                                                                     
        at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
        - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
        at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
        at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
        at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
        at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
        at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
        at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
        at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
        at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
        at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
        at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
        at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
        at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
        at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
        at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
        at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
        at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
        at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
        at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
                                                                                                                                                                                 
   Locked ownable synchronizers:                                                                                                                                                 
        - None


(Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).

Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:00:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 06:00:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1003) deadlock in TP.send
 - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26331567.1246010456699.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1003:
---------------------------

    Fix Version/s: 2.8


> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:09:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 06:09:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20546776.1246010997450.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473902#action_12473902 ] 

Bela Ban commented on JGRP-1003:
--------------------------------

Note that we don't support 2.7, I suggest switch to either 2.6.x or 2.8

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:09:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 06:09:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8490635.1246010997024.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473901#action_12473901 ] 

Bela Ban commented on JGRP-1003:
--------------------------------

The question is why does it hang in write(). The reason is that the peer doesn't call Socket.receive(), but we need to find out why.

A few things to try out:
- Use bundling: enable_bundling="true"
- Increase the socket buffer size: recv_buf_size / send_buf_size. The former is more important
- Use send queues in TCP: use_send_queues="true"
- Change the transport's thread pool config, a good one would be
 thread_pool.enabled="true"
         thread_pool.min_threads="2"
         thread_pool.max_threads="8"
         thread_pool.keep_alive_time="5000"
         thread_pool.queue_enabled="true"
         thread_pool.queue_max_size="10000"
         thread_pool.rejection_policy="discard"



> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:28:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Fri, 26 Jun 2009 06:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-97) JBoss Metadata Common
 2.0.0-SNAPSHOT
Message-ID: <21588560.1246012136598.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBoss Metadata Common 2.0.0-SNAPSHOT
------------------------------------

                 Key: JBJCA-97
                 URL: https://jira.jboss.org/jira/browse/JBJCA-97
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha1


metadata project will divide into some sub module, so we use common and rar instead of whole metadata jar
so far we use snapshot until  release version published

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:30:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Fri, 26 Jun 2009 06:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-98) JBoss Metadata Rar
	2.0.0-SNAPSHOT
Message-ID: <23628052.1246012256516.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBoss Metadata Rar 2.0.0-SNAPSHOT
---------------------------------

                 Key: JBJCA-98
                 URL: https://jira.jboss.org/jira/browse/JBJCA-98
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha1


metadata project will divide into some sub module, so we use common and rar instead of whole metadata jar
so far we use snapshot until  release version published

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:30:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Fri, 26 Jun 2009 06:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBJCA-68) JBoss Metadata
	1.0.2.Beta1
In-Reply-To: <29947535.1236869745527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28262152.1246012256736.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBJCA-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473904#action_12473904 ] 

Jeff Zhang commented on JBJCA-68:
---------------------------------

metadata project will divide into some sub module, so we use common and rar instead of whole metadata jar 


> JBoss Metadata 1.0.2.Beta1
> --------------------------
>
>                 Key: JBJCA-68
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-68
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha1
>
>
> Standalone + Test

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:32:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Fri, 26 Jun 2009 06:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBJCA-68) JBoss Metadata
	1.0.2.Beta1
In-Reply-To: <29947535.1236869745527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13720610.1246012376439.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang closed JBJCA-68.
---------------------------

    Resolution: Done


> JBoss Metadata 1.0.2.Beta1
> --------------------------
>
>                 Key: JBJCA-68
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-68
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha1
>
>
> Standalone + Test

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:39:56 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Fri, 26 Jun 2009 06:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3781209.1246012796972.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473905#action_12473905 ] 

Victor N commented on JGRP-1003:
--------------------------------

Yes, Bela,I will try with 2.8 and I am going to use TCP_NIO, this should be more safe.

As I know, there is no way to prevent socket write from hanging in blocking I/O approach in Java, because most of operating system does not allow to set  a socket write timeout. There is SO_TIMEOUT which means socket read timeout, but there is not timeout for writing. So I suppose that in blocking I/O it is not safe to do socket write inside a lock.

I do not think that socket buffer sizes can help. Also, thread pool settings may be different, but if some thread owns an exclusive lock forever, this will not help.

I will look into 2.8 code to see how enable_bundling and use_send_queues changes behavior.

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:42:56 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Fri, 26 Jun 2009 06:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10604794.1246012976924.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473906#action_12473906 ] 

Victor N commented on JGRP-1003:
--------------------------------

I can see that 2.8 uses the same code in TP.send:

out_stream_lock.lock();
        try {
            out_stream.reset();
            dos.reset();
            writeMessage(msg, dos, multicast);
            Buffer buf=new Buffer(out_stream.getRawBuffer(), 0, out_stream.size());
            doSend(buf, dest, multicast);
        }
        finally {
            out_stream_lock.unlock();
        }

So socket write is done inside a lock, and the behavior does not depend on enable_bundling and use_send_queues/

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 07:51:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 07:51:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <592074.1246017117060.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473924#action_12473924 ] 

Bela Ban commented on JGRP-1003:
--------------------------------

use_send_queues will *copy* the buffer and add it to a queue, then return immediately and release the lock. A separate thread will then send (and possibly block). This should help.

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 08:27:56 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Fri, 26 Jun 2009 08:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15797605.1246019276978.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473931#action_12473931 ] 

Victor N commented on JGRP-1003:
--------------------------------

Thanks, I see this in the code now!
use_send_queues should help.

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 08:42:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 26 Jun 2009 08:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1667) MBeans cannot
 have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19348086.1246020176645.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1667.
-----------------------------------

    Resolution: Rejected


close this as discussed.

> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 08:52:57 2009
From: jira-events at lists.jboss.org (Martin Gekeler (JIRA))
Date: Fri, 26 Jun 2009 08:52:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7059) Compatibility issue
 JBoss-5.1.0.GA -> JBoss-5.0.0.GA
Message-ID: <6442969.1246020777740.JavaMail.jira@cloud.prod.atl2.jboss.com>

Compatibility issue JBoss-5.1.0.GA -> JBoss-5.0.0.GA 
-----------------------------------------------------

                 Key: JBAS-7059
                 URL: https://jira.jboss.org/jira/browse/JBAS-7059
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
         Environment: JBoss-5.1.0.GA, Windows, local PC. 
            Reporter: Martin Gekeler


java.lang.ClassCastException: javax.naming.Reference cannot be cast to com.sdt.pellworm.ejb.Pellworm
	at com.sdt.pellworm.test.junit.TestPellwormEJB.testSayHello(TestPellwormEJB.java:29)
	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 junit.framework.TestCase.runTest(TestCase.java:168)
	at junit.framework.TestCase.runBare(TestCase.java:134)
	at junit.framework.TestResult$1.protect(TestResult.java:110)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.framework.TestResult.run(TestResult.java:113)
	at junit.framework.TestCase.run(TestCase.java:124)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

When i call the test case below from within eclipse I get this exception with JBoss-5.1.0.GA. 
I do not get it with JBoss-5.0.0.GA. 

Here's the code: 

public class TestPellwormEJB extends TestCase {

public void testSayHello() {
      InitialContext  ctx    = null; 
      Pellworm tsBean = null; 

      TestUtils.echoLogHello(this.getClass().getSimpleName(), this.getName()); 
      try {
         ctx    = new InitialContext(TestUtils.createInitialContext());
      } catch (NamingException e) {
         fail(e.getMessage()); 
      }
      try {
         // tsBean = (Pellworm) ctx.lookup("PellwormBean/remote");
         Object object = ctx.lookup("PellwormBean/remote");
         tsBean = (Pellworm) object; 
      } catch (NamingException e) {
         fail(e.getMessage()); 
      }
                  
      try {
         assertEquals("Hallo! Ich bin Pellworm. ", tsBean.sayHello());
      } catch (RemoteException e) {
         fail(e.getMessage()); 
      }
   }
   
}  

I haven't found a compatiblity issue in the release notes about this. 

Cheers, 
-M.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 08:54:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 26 Jun 2009 08:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1668) NPE when
 setting 'messageCounterHistoryDayLimit' prop on JMS Topics
Message-ID: <12342600.1246020896461.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics
-------------------------------------------------------------------

                 Key: JBMESSAGING-1668
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1668
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Configuration and Management
    Affects Versions: 1.4.3.GA, 1.4.0.SP3.CP08
            Reporter: Howard Gao
            Assignee: Howard Gao
             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 08:56:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 26 Jun 2009 08:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1667) MBeans
 cannot have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11217257.1246021016510.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox reopened JBMESSAGING-1667:
----------------------------------



The issue shouldn't be closed.

Like I mentioned in my earlier comment, we should explicit check that destination names do not contain forward slashes, log a warning and reject deployment if so.

> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 09:00:57 2009
From: jira-events at lists.jboss.org (Nicolas Heron (JIRA))
Date: Fri, 26 Jun 2009 09:00:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2141) In a rule flow,
 when the action is in MVEL, it is not possible to import classes
In-Reply-To: <5800231.1245931797780.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18727007.1246021257280.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473935#action_12473935 ] 

Nicolas Heron commented on JBRULES-2141:
----------------------------------------

the error is the same on a drl file in the then part
in mvel syntax, import are not considered

I have to explicitely put all the class name including package

instead of 
--------------
import fr.sopra.impo.ImpotPersonne

//some code

when 
then
    ImpotPersonne a = new ImpotPersonne()
end
-----------
i have to put
---------------
import fr.sopra.impo.ImpotPersonne

//some code

when 
then
    fr.sopra.impo.ImpotPersonne a = new fr.sopra.impo.ImpotPersonne()
end
-------------

> In a rule flow, when the action is in MVEL, it is not possible to import classes
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-2141
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2141
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-eclipse (flow)
>    Affects Versions: FUTURE
>            Reporter: Nicolas Heron
>            Assignee: Mark Proctor
>
> example : 
> -----------
> Long montant = (Long)context.getVariable("surimposition");
> System.out.println ("Surimposition : '" + montant + "'");
>  filter = new org.drools.runtime.ClassObjectFilter (fr.sopra.impot.Impot.class);
> java.util.Collection impots = context.getKnowledgeRuntime().getObjects(filter);
> if (impots.size()==1) {
> 	Impot impot = (Impot)impots.toArray()[0]; 
> 	impot.setMontantRedressement(montant);
> }
> ---------------
> it says  at design time : 
> Process 'ImpotProcess' [fr.sopra.impot.ImpotProcess]: Action node 'Traitement des resultats' [13] has invalid action: was expecting type: java.lang.Object; but found type: null.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 09:07:56 2009
From: jira-events at lists.jboss.org (Bernd Ruecker (JIRA))
Date: Fri, 26 Jun 2009 09:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2144) Drools 5 Plugin
 overwrite Drools 4 RuleFlow & DSL
Message-ID: <2129301.1246021676517.JavaMail.jira@cloud.prod.atl2.jboss.com>

Drools 5 Plugin overwrite Drools 4 RuleFlow & DSL
-------------------------------------------------

                 Key: JBRULES-2144
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2144
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
            Reporter: Bernd Ruecker
            Assignee: Mark Proctor


When using the Drools 5 Eclipse plugin you can select either Drools 4 or Drools 5 for a new project. This indicates, that both should be supported by the pugin.

But when opening a Drools 4 DSL with the editor, it seems to overwrite it with the Drools 5 format.

Same for RuleFlow.

Especially because the selection at the beginning suggets both versions are fully supported by the plugin, this is a bit annoying ;-)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 09:49:03 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 09:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7057) Update Kernel to
	2.0.8.GA
In-Reply-To: <28464517.1245960176528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24302469.1246024143487.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7057:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> Update Kernel to 2.0.8.GA
> -------------------------
>
>                 Key: JBAS-7057
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7057
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 09:49:03 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 09:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7056) Update to JBoss AOP
	2.1.3.GA
In-Reply-To: <4474870.1245959876452.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13966883.1246024143354.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7056:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> Update to JBoss AOP 2.1.3.GA
> ----------------------------
>
>                 Key: JBAS-7056
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7056
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 09:58:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 26 Jun 2009 09:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14903925.1246024736508.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-978:
-------------------------------------

    Attachment: UDP.java


A preliminary implementation of the algorithm to provide version consistent IP addresses.

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>         Attachments: UDP.java
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:07:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 26 Jun 2009 10:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <350291.1246025276508.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473963#action_12473963 ] 

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

Bela

I've attached a preliminary version of the algorithm to check for version consistent addresses in the case of UDP. Some utilities are missing, but this will give you the idea.

The idea is that if any of bind_addr, mcast_addr, diagnostics_addr or bind_interface are non-null, then the user has specified them and these should be used in calculating the complete set of addresses, those specified as well as required defaults.

bind_addr posed a challenge, as it is set based on any value passed for bind_interface. It just introduces more cases which need to be checked. I had to move bind_addr processing from TP.setProperties() to UDP.init() - it was happening too early and can be influenced by values for mcast_addr and diagnostics_addr.

I'm stuck doing EAP stuff at the moment (again) so it may not be until next week before I get a chance to finish this and commit it. Any feedback welcomed..

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>         Attachments: UDP.java
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:16:57 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 26 Jun 2009 10:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25334388.1246025817692.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473967#action_12473967 ] 

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

The other thing I would mention is that it appears that in the existing implementation, because bind_addr is set in TP.setProperties(), it means that by the time UDP.createSockets() is called, bind_addr is never non-null. Which means that the first few lines of code in UDP.creatSockets() (in particular, the one to choose first non-loopback address) never get called. Util.getBindAddress(props) doesn't seem to check for non-loopback addresses...

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>         Attachments: UDP.java
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:24:57 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 26 Jun 2009 10:24:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-84) Add support for
 hasAnnotation(Class) and getAnnotation(Class)
In-Reply-To: <11699216.1244821736498.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29572968.1246026297090.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JASSIST-84:
-----------------------------------

    Attachment:     (was: JASSIST-84.patch)


> Add support for hasAnnotation(Class) and getAnnotation(Class)
> -------------------------------------------------------------
>
>                 Key: JASSIST-84
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-84
>             Project: Javassist
>          Issue Type: Feature Request
>            Reporter: Jesper Pedersen
>            Assignee: Shigeru Chiba
>         Attachments: JASSIST-84.patch
>
>
> It would nice if Javassist had functionality to query 
>  boolean hasAnnotation(Class)
> and retrieve a single annotation 
>  Object getAnnotation(Class)
> for CtClass, CtBehavior and CtField.
> The attached implements this functionality against CVS HEAD.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:24:57 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 26 Jun 2009 10:24:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-84) Add support for
 hasAnnotation(Class) and getAnnotation(Class)
In-Reply-To: <11699216.1244821736498.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26845992.1246026297500.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JASSIST-84:
-----------------------------------

    Attachment: JASSIST-84.patch


> Add support for hasAnnotation(Class) and getAnnotation(Class)
> -------------------------------------------------------------
>
>                 Key: JASSIST-84
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-84
>             Project: Javassist
>          Issue Type: Feature Request
>            Reporter: Jesper Pedersen
>            Assignee: Shigeru Chiba
>         Attachments: JASSIST-84.patch
>
>
> It would nice if Javassist had functionality to query 
>  boolean hasAnnotation(Class)
> and retrieve a single annotation 
>  Object getAnnotation(Class)
> for CtClass, CtBehavior and CtField.
> The attached implements this functionality against CVS HEAD.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:27:10 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 26 Jun 2009 10:27:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <611492.1246026430187.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473970#action_12473970 ] 

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

Emanuel is right. What happens in your case is that the ejb-jar.xml is parsed first. Since it doesn't have a namespace, it's assumed to follow a DTD which means it'll be treated as EJB2. EJB2 don't use annotations, so annotation processing is skipped. And since ejb-jar.xml in your case doesn't describe any beans there is nothing to bind to the JNDI.
If you try describing EJB3 bean in EJB2 ejb-jar.xml you should get an error during deployment.
So, I am going to close it as "won't fix". You can try to convince the EJB3 team on the forums to make the namespace optional. But IMO that's not a good idea.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:28:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 26 Jun 2009 10:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8203529.1246026536537.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBMETA-208.
------------------------------------

    Resolution: Won't Fix


Won't be fixed.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:36:58 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 10:36:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7057) Update Kernel to
	2.0.8.GA
In-Reply-To: <28464517.1245960176528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26796254.1246027018118.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-7057.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> Update Kernel to 2.0.8.GA
> -------------------------
>
>                 Key: JBAS-7057
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7057
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:36:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 10:36:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7056) Update to JBoss AOP
	2.1.3.GA
In-Reply-To: <4474870.1245959876452.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13265274.1246027017853.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-7056.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
                       (was: JBossAS-5.2.0.Beta1)
       Resolution: Done


> Update to JBoss AOP 2.1.3.GA
> ----------------------------
>
>                 Key: JBAS-7056
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7056
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:36:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 10:36:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7056) Update to JBoss AOP
	2.1.3.GA
In-Reply-To: <4474870.1245959876452.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31168000.1246027017984.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7056:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> Update to JBoss AOP 2.1.3.GA
> ----------------------------
>
>                 Key: JBAS-7056
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7056
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:54:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 10:54:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6889) tests in
 tests-aop-scoped failing with IBM JDK
In-Reply-To: <7099808.1242045886541.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15095722.1246028097420.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6889.
----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


Resolved with JBoss AOP 2.1.3.GA and MC 2.0.8.GA.

> tests in tests-aop-scoped failing with IBM JDK
> ----------------------------------------------
>
>                 Key: JBAS-6889
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6889
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: TEST-org.jboss.test.aop.test.ScopedAnnotatedTestCase-aop-scoped.xml
>
>
> Tests in the tests-aop-scoped target of JBoss AS testsuite are failing.
> The tests are:
> org.jboss.test.aop.test.ScopedAnnotatedTestCase
> org.jboss.test.aop.test.ScopedAttachUnitTestCase
> org.jboss.test.aop.test.ScopedEarWithClassesInWebInfTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseLoadedScopedNoParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseLoadedScopedParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseNotLoadedScopedNoParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseNotLoadedScopedParentDelegationTestCase
> org.jboss.test.aop.test.ScopedUnitTestCase
> org.jboss.test.aop.test.ScopedWovenDependencyTestCase
> The error message is:
> javax.management.RuntimeErrorException
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:182)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: java.lang.ExceptionInInitializerError
> 	at java.lang.J9VMInternals.initialize(J9VMInternals.java:216)
> 	at org.jboss.test.aop.jdk15annotated.ScopedAnnotatedTester.testBinding(ScopedAnnotatedTester.java:50)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.aop.Domain$1.run(Domain.java:124)
> 	at org.jboss.aop.Domain$1.run(Domain.java:121)
> 	at java.security.AccessController.doPrivileged(AccessController.java:197)
> 	at org.jboss.aop.Domain.getDomainName(Domain.java:119)
> 	at org.jboss.test.aop.jdk15annotated.POJO$POJOAdvisor.initialise(POJO$POJOAdvisor.java)
> 	at org.jboss.test.aop.jdk15annotated.POJO$POJOAdvisor.<init>(POJO$POJOAdvisor.java)
> 	at org.jboss.test.aop.jdk15annotated.POJO.<clinit>(POJO.java)
> 	at java.lang.J9VMInternals.initializeImpl(Native Method)
> 	at java.lang.J9VMInternals.initialize(J9VMInternals.java:194)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:54:58 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 10:54:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12407759.1246028098359.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6888.
----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


Resolved with JBoss AOP 2.1.3.GA and MC 2.0.8.GA

> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Flavia Rainone
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: RunIt.java, server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:56:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 10:56:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6925) Tests in
 org.jboss.test.cluster
 failing with IBM JDK 1.5 - servlet jsp not deployed
In-Reply-To: <4280736.1242402226518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7381458.1246028217630.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6925.
----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


Resolved with JBoss AOP 2.1.3.GA and MC 2.0.8.GA

> Tests in org.jboss.test.cluster failing with IBM JDK 1.5 - servlet jsp not deployed
> -----------------------------------------------------------------------------------
>
>                 Key: JBAS-6925
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6925
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: server.log-JBAS-6925, server.log-JBAS-6925-sun
>
>
> Some clustered tests are failing with IBM JDK 1.5.
> This is the list:
> org.jboss.test.cluster.defaultcfg.web.field.test.FieldBasedSessionPassivationTestCase
> org.jboss.test.cluster.defaultcfg.web.field.test.ScopedFieldBasedTestCase
> org.jboss.test.cluster.multicfg.web.field.test.FieldBasedTestCase
> org.jboss.test.cluster.multicfg.web.field.test.UndeployFieldTestCase
> In total this cause 105 failures in the AS testsuite (the test cases are run several times with different clustering configuration).
> The failures all look the same. This is an example from org.jboss.test.cluster.defaultcfg.web.field.test.FieldBasedSessionPassivationTestCase.testSessionPassivationWMaxIdle:
> Get OK with url: http://10.16.93.37:8080/http-field-pass/setSession.jsp responseCode: 500
> junit.framework.AssertionFailedError: Get OK with url: http://10.16.93.37:8080/http-field-pass/setSession.jsp responseCode: 500
> 	at org.jboss.test.cluster.testutil.WebTestBase.makeGet(WebTestBase.java:115)
> 	at org.jboss.test.cluster.defaultcfg.web.test.SessionPassivationTestCase.testSessionPassivationWMaxIdle(SessionPassivationTestCase.java:155)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> In the server log, you can see errors like this:
> 17:14:48,650 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception
> java.lang.NullPointerException
> 	at org.jboss.aop.Domain$1.run(Domain.java:124)
> 	at org.jboss.aop.Domain$1.run(Domain.java:121)
> 	at java.security.AccessController.doPrivileged(AccessController.java:197)
> 	at org.jboss.aop.Domain.getDomainName(Domain.java:119)
> 	at org.jboss.test.cluster.web.aop.Person$PersonAdvisor.initialise(Person$PersonAdvisor.java)
> 	at org.jboss.test.cluster.web.aop.Person$PersonAdvisor.<init>(Person$PersonAdvisor.java)
> 	at org.jboss.test.cluster.web.aop.Person.<clinit>(Person.java)
> 	at java.lang.J9VMInternals.initializeImpl(Native Method)
> 	at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
> 	at org.apache.jsp.setSession_jsp._jspService(setSession_jsp.java:65)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94)
> 	at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:810)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 11:31:56 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 26 Jun 2009 11:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-84) Add support for
 hasAnnotation(Class) and getAnnotation(Class)
In-Reply-To: <11699216.1244821736498.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16096190.1246030316581.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-84.
----------------------------------

    Fix Version/s: 3.11.0.GA
       Resolution: Done


I applied the patch.

> Add support for hasAnnotation(Class) and getAnnotation(Class)
> -------------------------------------------------------------
>
>                 Key: JASSIST-84
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-84
>             Project: Javassist
>          Issue Type: Feature Request
>            Reporter: Jesper Pedersen
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>         Attachments: JASSIST-84.patch
>
>
> It would nice if Javassist had functionality to query 
>  boolean hasAnnotation(Class)
> and retrieve a single annotation 
>  Object getAnnotation(Class)
> for CtClass, CtBehavior and CtField.
> The attached implements this functionality against CVS HEAD.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 11:39:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 11:39:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7651458.1246030797461.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473986#action_12473986 ] 

Bela Ban commented on JGRP-1003:
--------------------------------

Let me know if this fixes the issue, so I can close it. I plan on rewriting a TCP transport once we're on JDK 1.7 anyway, to run on NIO, so I don't want to make too many changes to TCP as it stands for now

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 12:10:57 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 26 Jun 2009 12:10:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-549) ConnectionTable:
 spurious Connection instances on concurrent connects
In-Reply-To: <10580511.1183710592881.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6262892.1246032657114.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473989#action_12473989 ] 

Richard Achmatowicz commented on JGRP-549:
------------------------------------------

Looks as though the unit test ConnectionTableTest.testConcurrentConnect() which appears in HEAD:/tests/junit-functional was not pulled back to 2.4.

I'm adding the test to Branch_2_4 version of ConnectionTableTest.
It had to be adjusted slightly as the interface of CyclicBarrier changed from EDU.oswego.cs.dl.util.concurrent to java.util.concurrent. 

> ConnectionTable: spurious Connection instances on concurrent connects
> ---------------------------------------------------------------------
>
>                 Key: JGRP-549
>                 URL: https://jira.jboss.org/jira/browse/JGRP-549
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6
>
>
> If we have members A and B, and they don't yet have connections to each other, and start sending messages to each other at the exact same time, then we run into the following scenario:
> - A attempts to connect to B (new Socket())
> - B attempts to connect to A
> - A accepts B's connection and adds an entry for B into its table
> - B adds an entry for A into its table
> - B gets the accept() from A, but doesn't add the new Connection into its table because there is already a Connection. This leads to a spurious Connection object, which will only be closed and garbage collected once A or B leaves the cluster
> - We used to close Connections which were already in the table, but this lead to ping-pong effects where concurrent initial senders always closed each others connections
> - Even worse: a new Socket() always creates a new Connection object and places it into the table, *regardless* of whether a Connection for a given destination already exists or not !
> GOAL:
> #1 Have only 1 TCP connection between any 2 members
> #2 Establish a handshaking mechanism, to avoid spurious connections
> SOLUTION:
> - When A establishes a connection to B, A needs to get agreement from B first (and vice versa)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 13:10:56 2009
From: jira-events at lists.jboss.org (Calvin Lin (JIRA))
Date: Fri, 26 Jun 2009 13:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7037) JBossAS 5.x fails to
 use EJB's
 security domain in jboss.xml when the call is from web container
In-Reply-To: <2821553.1245299576703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30788021.1246036256665.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Calvin Lin updated JBAS-7037:
-----------------------------

    Workaround Description: 
Our workaround for standalone JBoss AS is to add "CLIENT_LOGIN_MODULE" application-policy in login-config.xml and use that for EJB container authentication.
For clustering environment, the workaround is to add "BYPASSED-SECURITY" application-policy in login-config.xml to handle the EJB container authentication.

  was:Our workaround is to add "CLIENT_LOGIN_MODULE" application-policy in login-config.xml and use that for EJB container authentication.



> JBossAS 5.x fails to use EJB's security domain in jboss.xml when the call is from web container
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7037
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: Problem found on Windows platform
>            Reporter: Calvin Lin
>            Assignee: Stefan Guilhen
>             Fix For: JBossAS-5.0.2.GA
>
>         Attachments: ConfigFiles-lib.zip, JBAS-jira-authenBug.zip
>
>
> A degredation from JBoss 4.0.x and 4.2.x to JBoss 5.0.1.GA and JBoss 5.1.0.GA.
> We noticed that the JAAS login in EJB container always picks up the Web app's security domain when the client login is originated from a web application client.  The security domain specified in EJB container's jboss.xml is always ignored in this situation.
> The detailed problem description is posted on JBoss forum:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156863

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 13:21:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 26 Jun 2009 13:21:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1669) data
 directorires are
 located under ./bin when running on the application server.
Message-ID: <8252217.1246036917141.JavaMail.jira@cloud.prod.atl2.jboss.com>

data directorires are located under ./bin when running on the application server.
---------------------------------------------------------------------------------

                 Key: JBMESSAGING-1669
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1669
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta3
            Reporter: Clebert Suconic
            Assignee: Clebert Suconic
             Fix For: 2.0.0


When running JBossMessaging 2 inside JBoss AS, the data directory, paging and large-message-dir are located under ./bin

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 13:21:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 26 Jun 2009 13:21:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1669) data
 directorires are
 located under ./bin when running on the application server.
In-Reply-To: <8252217.1246036917141.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20267026.1246036917577.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1669.
----------------------------------------

    Resolution: Done


> data directorires are located under ./bin when running on the application server.
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1669
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1669
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> When running JBossMessaging 2 inside JBoss AS, the data directory, paging and large-message-dir are located under ./bin

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 14:46:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Fri, 26 Jun 2009 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1858) NPE if in
 resource-env-ref no injection target is specified
Message-ID: <15528450.1246042016731.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE if in resource-env-ref no injection target is specified
-----------------------------------------------------------

                 Key: EJBTHREE-1858
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1858
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: 1.1.7
            Reporter: Wolfgang Knauf
         Attachments: ResourceEnvRefNPE.jar

If an ENC entry for java:/comp/EJBContext is declared and NO injection target is specified, this results in a NPE.

			<resource-env-ref>
				<resource-env-ref-name>EnvNameOfSessionContext</resource-env-ref-name>
 				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
				<mapped-name>java:comp/EJBContext</mapped-name>
			</resource-env-ref>

The exception is:
...
Caused by: java.lang.NullPointerException
	at org.jboss.injection.InjectionUtil.createInjectors(InjectionUtil.java:105)
	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:227)
	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:343)
	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:597)
	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:434)
	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:543)
	... 69 more

Looking at the code in ResourceHandler.loadXmlResourceEnvRefs, this is the only place where the check "if(envRef.getInjectionTargets() != null)" is missing ;-).

I will attach a sample.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 14:46:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Fri, 26 Jun 2009 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1858) NPE if in
 resource-env-ref no injection target is specified
In-Reply-To: <15528450.1246042016731.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18657196.1246042016926.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolfgang Knauf updated EJBTHREE-1858:
-------------------------------------

    Attachment: ResourceEnvRefNPE.jar


Full sampe, including code. Deployment to JBoss 5.1.0GA with updated EJB-plugin 1.1.7 will fail.

> NPE if in resource-env-ref no injection target is specified
> -----------------------------------------------------------
>
>                 Key: EJBTHREE-1858
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1858
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>         Attachments: ResourceEnvRefNPE.jar
>
>
> If an ENC entry for java:/comp/EJBContext is declared and NO injection target is specified, this results in a NPE.
> 			<resource-env-ref>
> 				<resource-env-ref-name>EnvNameOfSessionContext</resource-env-ref-name>
>  				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 			</resource-env-ref>
> The exception is:
> ...
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.InjectionUtil.createInjectors(InjectionUtil.java:105)
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:227)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:343)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:597)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:434)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:543)
> 	... 69 more
> Looking at the code in ResourceHandler.loadXmlResourceEnvRefs, this is the only place where the check "if(envRef.getInjectionTargets() != null)" is missing ;-).
> I will attach a sample.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 14:53:58 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Fri, 26 Jun 2009 14:53:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1856) NPE if
 "res-type" element
 is missing in ejb-jar.xml for injection of SessionContext
In-Reply-To: <8850904.1245957128139.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30816898.1246042438371.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474022#action_12474022 ] 

Wolfgang Knauf commented on EJBTHREE-1856:
------------------------------------------

Thanks, with the new plugin it works. I should have searched for the error message before filing a JIRA.

My initial sample was probably not valid, I should have used a "resource-env-ref" element (which is for injection of "anything else") instead of "res-ref".

> NPE if "res-type" element is missing in ejb-jar.xml for injection of SessionContext
> -----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1856
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1856
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>
> I have an ejb-jar.xml for an annotation free EJB. I try to inject a SessionContext.
> With JBoss 5.0, this snippet worked:
> 			<resource-ref>
> 				<res-ref-name>NameDoesNotCare</res-ref-name>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.some.package.SecuredBean</injection-target-class>
> 					<injection-target-name>mySessionContext</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> With JBoss 5.1, this fails with a NullPointerException (EJB is "SecuredBean" in "SecurityEJB.jar"):
> 21:02:02,890 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 21:02:02,890 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/C:/temp/jboss-5.1.0.GA/server/default/tmp/jsr88/Security.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying SecurityEJB.jar: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
> 	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:1210)
> 	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.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:413)
> 	at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.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 sun.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	at sun.reflect.GeneratedMethodAccessor304.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.GeneratedMethodAccessor303.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> 	at sun.rmi.transport.Transport$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
> 	... 68 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
> 	... 69 more
> I found that "<res-type>javax.ejb.SessionContext</res-type>" is missing. I think the deployment should raise a meaningful error message.
> I can provide you with a full sample if required.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 15:18:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Fri, 26 Jun 2009 15:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7034) Outdated/missing
 schema files on website
In-Reply-To: <15960137.1245267836412.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5042292.1246043936542.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolfgang Knauf updated JBAS-7034:
---------------------------------

    Description: 
Some xsd files are missing or are outdated (even with validation errors) at http://www.jboss.org/j2ee/schema/

Please update from trunk ( http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/ ):

jboss-ds_5_0.xsd (missing, see also https://jira.jboss.org/jira/browse/JBMETA-210 )
jboss-web_5_1.xsd (missing, see also https://jira.jboss.org/jira/browse/JBMETA-210 )
jboss-client_5_1.xsd (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-210 )
jboss-ra_1_0.xsd  (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-210 )
jboss_common_5_1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.1.xsd (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.0.xsd (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-185 )


bean-deployer_1_0.xsd (missing)
bean-deployer_2_0.xsd (missing)
jboss-beans-common_2_0.xsd (missing)
policy_1_0.xsd (missing)
Note: they do not validate, too (invalid schema locations, and a (maybe false) validation error, see https://jira.jboss.org/jira/browse/JBMICROCONT-446 ), but they should be available on the website anyway.

  was:
Some xsd files are missing or are outdated at http://www.jboss.org/j2ee/schema/

Please update from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/):

jboss-ds_5_0.xsd (missing)
jboss-web_5_1.xsd (missing)
jboss_common_5_1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.0.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-185 )
(some still do not validate because of invalid schema locations, so they must be updated again if https://jira.jboss.org/jira/browse/JBMETA-210 is fixed)

bean-deployer_1_0.xsd (missing)
bean-deployer_2_0.xsd (missing)
jboss-beans-common_2_0.xsd (missing)
policy_1_0.xsd (missing)
Note: they do not validate, too (invalid schema locations, and a (maybe false) validation error, see https://jira.jboss.org/jira/browse/JBMICROCONT-446 ), but they should be available on the website anyway.



> Outdated/missing schema files on website
> ----------------------------------------
>
>                 Key: JBAS-7034
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7034
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Wolfgang Knauf
>
> Some xsd files are missing or are outdated (even with validation errors) at http://www.jboss.org/j2ee/schema/
> Please update from trunk ( http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/ ):
> jboss-ds_5_0.xsd (missing, see also https://jira.jboss.org/jira/browse/JBMETA-210 )
> jboss-web_5_1.xsd (missing, see also https://jira.jboss.org/jira/browse/JBMETA-210 )
> jboss-client_5_1.xsd (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-210 )
> jboss-ra_1_0.xsd  (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-210 )
> jboss_common_5_1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
> jboss_5.1.xsd (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-200 )
> jboss_5.0.xsd (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-185 )
> bean-deployer_1_0.xsd (missing)
> bean-deployer_2_0.xsd (missing)
> jboss-beans-common_2_0.xsd (missing)
> policy_1_0.xsd (missing)
> Note: they do not validate, too (invalid schema locations, and a (maybe false) validation error, see https://jira.jboss.org/jira/browse/JBMICROCONT-446 ), but they should be available on the website anyway.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 15:35:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 26 Jun 2009 15:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-549) ConnectionTable:
 spurious Connection instances on concurrent connects
In-Reply-To: <10580511.1183710592881.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18585119.1246044956425.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474026#action_12474026 ] 

Richard Achmatowicz commented on JGRP-549:
------------------------------------------

Done.

> ConnectionTable: spurious Connection instances on concurrent connects
> ---------------------------------------------------------------------
>
>                 Key: JGRP-549
>                 URL: https://jira.jboss.org/jira/browse/JGRP-549
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6
>
>
> If we have members A and B, and they don't yet have connections to each other, and start sending messages to each other at the exact same time, then we run into the following scenario:
> - A attempts to connect to B (new Socket())
> - B attempts to connect to A
> - A accepts B's connection and adds an entry for B into its table
> - B adds an entry for A into its table
> - B gets the accept() from A, but doesn't add the new Connection into its table because there is already a Connection. This leads to a spurious Connection object, which will only be closed and garbage collected once A or B leaves the cluster
> - We used to close Connections which were already in the table, but this lead to ping-pong effects where concurrent initial senders always closed each others connections
> - Even worse: a new Socket() always creates a new Connection object and places it into the table, *regardless* of whether a Connection for a given destination already exists or not !
> GOAL:
> #1 Have only 1 TCP connection between any 2 members
> #2 Establish a handshaking mechanism, to avoid spurious connections
> SOLUTION:
> - When A establishes a connection to B, A needs to get agreement from B first (and vice versa)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 15:57:07 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Fri, 26 Jun 2009 15:57:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <16571178.1246046227969.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7032:
---------------------------------

    Priority: Blocker  (was: Major)


If this is due to a conflict between the Embedded Console RichFaces jars and those of a users application, as described in the recent forum post, then that is a blocker

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 16:33:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 16:33:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6962)
 org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
In-Reply-To: <994948.1242838745393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27900180.1246048437843.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6962:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
> ----------------------------------------------------------------------
>
>                 Key: JBAS-6962
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6962
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: TEST-org.jboss.test.cmp2.commerce.CompleteUnitTestCase.xml
>
>
> With IBM JDK 1.6 the test testJBossQL fails with this message:
> Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> junit.framework.AssertionFailedError: Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> 	at org.jboss.test.cmp2.commerce.QueryTest.testJBossQL(QueryTest.java:169)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)
> It's strange that with IBM 1.6 the failure does not happen in that test, but in different - testEJBQL:
> expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> junit.framework.ComparisonFailure: expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> 	at org.jboss.test.cmp2.commerce.QueryTest.testEJBQL(QueryTest.java:329)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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:193)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Fri Jun 26 16:33:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 16:33:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6934) Tests in
 org.jboss.test.cluster failing with IBM JDK 1.5 - Failed to start
 cluster/http/jboss-web-test-service.xml
In-Reply-To: <23484241.1242648377491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6549361.1246048437525.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6934:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> Tests in org.jboss.test.cluster failing with IBM JDK 1.5 - Failed to start cluster/http/jboss-web-test-service.xml
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6934
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6934
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Some clustered tests are failing with this error message:
> Failed to start cluster/http/jboss-web-test-service.xml
> org.jboss.cache.pojo.PojoCacheException: Failed to start cluster/http/jboss-web-test-service.xml
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.<init>(PojoCacheImpl.java:63)
> 	at org.jboss.cache.pojo.PojoCacheFactory.createCache(PojoCacheFactory.java:42)
> 	at org.jboss.test.cluster.testutil.SessionTestUtil.getConfiguration(SessionTestUtil.java:147)
> 	at org.jboss.test.cluster.testutil.SessionTestUtil.createCache(SessionTestUtil.java:136)
> 	at org.jboss.test.cluster.testutil.CacheConfigTestSetup.setUp(CacheConfigTestSetup.java:84)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: org.jboss.cache.config.ConfigurationException: Unable to build interceptor chain
> 	at org.jboss.cache.factories.InterceptorChainFactory.construct(InterceptorChainFactory.java:229)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:318)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.DefaultCacheFactory.bootstrap(DefaultCacheFactory.java:155)
> 	at org.jboss.cache.DefaultCacheFactory.createAndWire(DefaultCacheFactory.java:141)
> 	at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:120)
> 	at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:93)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.<init>(PojoCacheImpl.java:58)
> Caused by: java.lang.TypeNotPresentException: Type net.jcip.annotations.ThreadSafe not present
> 	at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:38)
> 	at com.ibm.oti.reflect.AnnotationHelper.getDeclaredAnnotations(AnnotationHelper.java:50)
> 	at java.lang.Class.getDeclaredAnnotations(Class.java:1620)
> 	at java.lang.Class.getAnnotations(Class.java:1581)
> 	at java.lang.Class.getAnnotation(Class.java:1561)
> 	at java.lang.Class.isAnnotationPresent(Class.java:1648)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:252)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.InterceptorChainFactory.createInterceptor(InterceptorChainFactory.java:60)
> 	at org.jboss.cache.factories.InterceptorChainFactory.buildInterceptorChain(InterceptorChainFactory.java:75)
> 	at org.jboss.cache.factories.InterceptorChainFactory.construct(InterceptorChainFactory.java:225)
> Caused by: java.lang.ClassNotFoundException: net.jcip.annotations.ThreadSafe
> 	at java.lang.Class.forName(Class.java:163)
> 	at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:33)
> This is the list of the tests failing because of this: 
> org.jboss.test.cluster.defaultcfg.simpleweb.test.AttributeBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.BuddyReplicationFailoverUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.BuddyReplicationToPassivatedSessionUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.ClusteredSessionNotificationPolicyTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.FieldBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.JBossCacheManagerConfigurationUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.ReplicationToPassivatedSessionUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionCountUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionExpirationUnitTestCase
> In total it causes 29 failures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 16:33:58 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 16:33:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6968)
 org.jboss.test.spring.test.SpringClusterTestCase failing with IBM JDK 1.5
In-Reply-To: <32698421.1243001398195.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15115907.1246048438084.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6968:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> org.jboss.test.spring.test.SpringClusterTestCase failing with IBM JDK 1.5
> -------------------------------------------------------------------------
>
>                 Key: JBAS-6968
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6968
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: spring-server.log
>
>
> org.jboss.test.spring.test.SpringClusterTestCase is failing with this message:
> testStandalone	Failure	N/A
> junit.framework.AssertionFailedError
> 	at org.jboss.test.spring.test.SpringClusterTestCase.testStandalone(SpringClusterTestCase.java:43)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> In the server log you can see:
> ...
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/lib/spring-cluster-pojos.jar/" is in error due to the following reason(s): java.lang.ClassNotFoundException: net.jcip.annotations.ThreadSafe
> ...
> Which shows that it is again the same problem with net.jcip.annotations.ThreadSafe missing in IBM JDK as discussed here JBAS-6934 and JBAS-6428.
> Solution: Ensure that jcip-annotations.jar gets copied to server/springdeployer/lib/ when the config is created.
> A. Add jcip-annotations.jar to server/default/lib (it is 2.6 KB) - springdeployer is created out of default
> B. Change testsuite/build.xml to make ant copy jcip-annotations.jar from server/all/lib/ to server/springdeployer/lib/ - don't know how to do that easily
> A. seems easier to do.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 16:33:58 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 16:33:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6967)
 org.jboss.test.security.test.HttpsUnitTestCase failing with IBM JDK
In-Reply-To: <27953188.1242999477645.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23041034.1246048438298.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6967:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> org.jboss.test.security.test.HttpsUnitTestCase failing with IBM JDK
> -------------------------------------------------------------------
>
>                 Key: JBAS-6967
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6967
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: TEST-org.jboss.test.security.test.HttpsUnitTestCase-tests-security-basic-unit.xml
>
>
> When running the AS testsuite, this test case shows an error:
> org.jboss.test.security.test.HttpsUnitTestCase
> The error message is:
> unknown	Error	N/A
> java.lang.NullPointerException
> 	at java.security.Security.insertProviderAt(Security.java:357)
> 	at java.security.Security.addProvider(Security.java:406)
> 	at org.jboss.test.security.test.HttpsUnitTestCase$1.setUp(HttpsUnitTestCase.java:171)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> When you look in the source code, this is the line where it fails:
> Security.addProvider(SecurityProviderUtil.getJSSEProvider());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 16:35:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 26 Jun 2009 16:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1839) Implement
 POJO-based, @ManagedObject Session Metrics
In-Reply-To: <32587729.1243384676916.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8898275.1246048556984.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1839.
-------------------------------------------

    Resolution: Done


> Implement POJO-based, @ManagedObject Session Metrics
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1839
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1839
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: metrics-deployer
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.8
>
>         Attachments: metrics.patch
>
>
> Defined by JBAS-6624.
> Consoles need Statistics accessible via ProfileService and jboss-management @ManagedObjects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 16:35:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 26 Jun 2009 16:35:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1831) Clean up
	dependency chains
In-Reply-To: <13433231.1242136368008.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25088041.1246048557441.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated EJBTHREE-1831:
------------------------------------------

    Fix Version/s: 1.1.9
                       (was: 1.1.8)


> Clean up dependency chains
> --------------------------
>
>                 Key: EJBTHREE-1831
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1831
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: as-int, ejb3
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.9
>
>
> The true order should be:
> jboss-ejb3 > as-int > AS
> jboss-ejb3 > Plugin
> Whereas now as-int goes into Plugin.  Also endpoint-deployer should be included in as-int and Plugin, and not explicitly declared by AS itself.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 16:35:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 26 Jun 2009 16:35:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1814)
 NoPassivationCache does not obey maxSize
In-Reply-To: <17499438.1240909569920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19162544.1246048557672.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated EJBTHREE-1814:
------------------------------------------

    Fix Version/s: 1.1.9
                       (was: 1.1.8)


> NoPassivationCache does not obey maxSize
> ----------------------------------------
>
>                 Key: EJBTHREE-1814
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1814
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: cache
>            Reporter: Carlo de Wolf
>             Fix For: 1.1.9
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 17:03:07 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 26 Jun 2009 17:03:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1858) NPE if in
 resource-env-ref no injection target is specified
In-Reply-To: <15528450.1246042016731.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <782835.1246050187841.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1858:
--------------------------------------

    Assignee: jaikiran pai


> NPE if in resource-env-ref no injection target is specified
> -----------------------------------------------------------
>
>                 Key: EJBTHREE-1858
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1858
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>         Attachments: ResourceEnvRefNPE.jar
>
>
> If an ENC entry for java:/comp/EJBContext is declared and NO injection target is specified, this results in a NPE.
> 			<resource-env-ref>
> 				<resource-env-ref-name>EnvNameOfSessionContext</resource-env-ref-name>
>  				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 			</resource-env-ref>
> The exception is:
> ...
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.InjectionUtil.createInjectors(InjectionUtil.java:105)
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:227)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:343)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:597)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:434)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:543)
> 	... 69 more
> Looking at the code in ResourceHandler.loadXmlResourceEnvRefs, this is the only place where the check "if(envRef.getInjectionTargets() != null)" is missing ;-).
> I will attach a sample.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 17:03:08 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Fri, 26 Jun 2009 17:03:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20326685.1246050188122.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7051:
---------------------------------

    Assignee: Jason T. Greene  (was: Scott M Stark)


How come the queue-example-service.xml is even able to be deployed...

I thought only JBossMessaging was deployed in JBAS5.0

<?xml version="1.0" encoding="UTF-8"?>
<server>
   <mbean code="org.jboss.mq.server.jmx.Queue"
      name="jboss.mq.destination:service=Queue,name=tutorial">
      <attribute name="JNDIName">queue/tutorial/example</attribute>
      <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
   </mbean>

   <mbean code="org.jboss.mq.server.jmx.Queue"
      name="jboss.mq.destination:service=Queue,name=defaultedtutorial">
      <attribute name="JNDIName">queue/tutorial/defaultedexample</attribute>
      <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
   </mbean>
</server>



> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         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.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         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.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.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         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.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 17:04:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 26 Jun 2009 17:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5328584.1246050296940.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474031#action_12474031 ] 

Ian Springer commented on JBAS-7051:
------------------------------------

Note, the file to look at inside the attached ejb-jar is META-INF/queue-example-service.xml.


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         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.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         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.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.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         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.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 17:14:08 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 26 Jun 2009 17:14:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <24940004.1246050848049.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474032#action_12474032 ] 

Ian Springer commented on JBAS-7032:
------------------------------------

I started a post on this issue in the JBossAS5 Users forum:

  http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157695


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 18:09:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 26 Jun 2009 18:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-514) Improve sar
 generation for varia module
In-Reply-To: <10543048.1235752039200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22163670.1246054196427.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474041#action_12474041 ] 

Paul Gier commented on JBBUILD-514:
-----------------------------------

Replaced the extra Ant file with using the assembly plugin.  Due to MJBOSSPACK-25 we have to wait until the next release of the jboss packaging plugin before the assembly plugin can create .sar artifacts instead of -sar.jar.

> Improve sar generation for varia module
> ---------------------------------------
>
>                 Key: JBBUILD-514
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-514
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Ant is currently used to generate the .sar files in the varia module.  Possibly the jboss-packaging maven plugin could be used to generate these files.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 18:11:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 26 Jun 2009 18:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-514) Improve sar
 generation for varia module
In-Reply-To: <10543048.1235752039200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27912347.1246054316654.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier closed JBBUILD-514.
-----------------------------

    Resolution: Done


> Improve sar generation for varia module
> ---------------------------------------
>
>                 Key: JBBUILD-514
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-514
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Ant is currently used to generate the .sar files in the varia module.  Possibly the jboss-packaging maven plugin could be used to generate these files.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 18:23:56 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Fri, 26 Jun 2009 18:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6918) "trackByTxn" always
 gets
 displayed as "false" in the output of the "listStatistics" operation for
 Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20450662.1246055036692.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-6918:
---------------------------------

    Priority: Minor  (was: Major)


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 19:38:56 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Fri, 26 Jun 2009 19:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <10982794.1246059536707.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474050#action_12474050 ] 

John Ament commented on JBAS-7032:
----------------------------------

Ian - your comments in the thread indicate that I'm doing that stuff that I haven't tried yet.  As of yet, I haven't changed the classloading configuration yet.  

Is the implication that I either downgrade my richfaces or upgrade the admin-console richfaces, and it'll all go away?

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 22:22:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 26 Jun 2009 22:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1668) NPE when
 setting 'messageCounterHistoryDayLimit' prop on JMS Topics
In-Reply-To: <12342600.1246020896461.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30012374.1246069376761.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1668.
-----------------------------------

    Resolution: Done


done

> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics
> -------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1668
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1668
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.3.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 22:24:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 26 Jun 2009 22:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS Topics
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17418575.1246069496575.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao resolved JBAS-6783.
------------------------------

    Resolution: Done


fixed

> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics
> -------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Howard Gao
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:
> <attribute name="MessageCounterHistoryDayLimit">10</attribute>
> Caused by: java.lang.NullPointerException
> 	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
> 	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)
> Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .
> The problem is that the property is only expected to be set at runtime, AFTER the topic has started:
>  Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 27 04:18:56 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Sat, 27 Jun 2009 04:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14539415.1246090736888.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Kennard reopened JBMETA-208:
------------------------------------



> If you try describing EJB3 bean in EJB2 ejb-jar.xml you should get an error during deployment.

Yes you should, but you don't.

Please reopen this issue. If you DID get an error during deployment, I would agree the current 'namespace versus DTD' handling is fine. As it is, you get an obscure JBMETA-4 warning and everything fails silently.


> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 27 04:52:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Sat, 27 Jun 2009 04:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1670) Disallow
 forward slashes in jms destinations
Message-ID: <15439568.1246092776416.JavaMail.jira@cloud.prod.atl2.jboss.com>

Disallow forward slashes in jms destinations
--------------------------------------------

                 Key: JBMESSAGING-1670
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1670
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
            Assignee: Tim Fox
             Fix For: 2.0.0


We need to disallow forward slashes in JMS destination names since they won't be able to be deployed in JNDI since the slash will be interperted as a subcontext by JNDI

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 27 04:54:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Sat, 27 Jun 2009 04:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1671) Consider
 storing JMS destinations in their own journal instance
Message-ID: <11315556.1246092896416.JavaMail.jira@cloud.prod.atl2.jboss.com>

Consider storing JMS destinations in their own journal instance
---------------------------------------------------------------

                 Key: JBMESSAGING-1671
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1671
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
            Assignee: Tim Fox
             Fix For: 2.0.0


We should consider storing JMS destinations in their own journal instance, and automatically deploy them into JNDI and management from this. This would mean that any JMS destinations created via the management interface would get redeployed on startup, which is not currently the case

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 27 05:35:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Sat, 27 Jun 2009 05:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4422648.1246095356857.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474073#action_12474073 ] 

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

The deployment descriptor dictates what and how should be deployed (that's why it is called deployment descriptor). EJB2 deployment descriptor means the deployment is EJB2. And since the descriptor is empty you get nothing deployed. If you did try to describe an EJB3 bean in EJB2 deployment descriptor you would get an error. Do you have a testcase that shows that's not the case?

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 27 09:53:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Sat, 27 Jun 2009 09:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <8585481.1246110836918.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474075#action_12474075 ] 

Ian Springer commented on JBAS-7032:
------------------------------------

Hi John,

Yeah, that would be a workaround. However, you really should not have to do this (i.e. deploying the admin-console should not force you to change any of your other apps), so there is probably something that needs fixing in the admin-console's classloading configuration and/or JBAS itself. As you can see, this issue has been raised to Blocker, so we consider this an important issue to get to the bottom of.


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 27 09:53:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 27 Jun 2009 09:53:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1000) COMPRESS corrupts
	some messages
In-Reply-To: <7560851.1245854756549.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <710002.1246110837087.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1000:
---------------------------

    Fix Version/s: 2.4.7
                   2.6.11
                   2.8


> COMPRESS corrupts some messages
> -------------------------------
>
>                 Key: JGRP-1000
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1000
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.5
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> COMPRESS.down() stores the compressed message in a temporary buffer the same size as the original message.
> If the compressed size of a message is larger than the original, then part of the message is lost, with no errors reported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 27 09:58:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 27 Jun 2009 09:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1000) COMPRESS corrupts
	some messages
In-Reply-To: <7560851.1245854756549.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23889151.1246111136499.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474077#action_12474077 ] 

Bela Ban commented on JGRP-1000:
--------------------------------

It sucks that a compressed payload would be *greater* than the uncompressed payload ! Therefore I suggest the following change: 
- Allocate a buffer with the length computed as mentioned above
- If the compressed payload is >= the regular payload, we send the regular payload and don't attach a CompressHeader
- Else we send the compressed payload (with a CompressHeader)

WDYT ?

> COMPRESS corrupts some messages
> -------------------------------
>
>                 Key: JGRP-1000
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1000
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.5
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> COMPRESS.down() stores the compressed message in a temporary buffer the same size as the original message.
> If the compressed size of a message is larger than the original, then part of the message is lost, with no errors reported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 00:47:57 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Sun, 28 Jun 2009 00:47:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10474790.1246164477242.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474091#action_12474091 ] 

Richard Kennard commented on JBMETA-208:
----------------------------------------

> If you did try to describe an EJB3 bean in EJB2 deployment descriptor you would get an error

Fair enough. But in general EJB3 beans are not described in the deployment descriptor: they are described with an annotation on the class.

If you have a bean annotated @Stateful or @Stateless in your JAR, but your JAR has an EJB2 deployment descriptor, you should get an error. But you don't. You DO get a JBMETA-4 warning, but this is not very clear as to what the problem is.

I am sorry I haven't been explaining myself very well. I hope the problem is now clear. What happened was I upgraded a JBoss 4.2.3.GA app to JBoss 5.1.0. The app used EJB3 annotations but forgot the namespace on the ejb-jar.xml (hence accidentally making it an EJB2 descriptor). This worked fine on JBoss 4.2.3.GA, but JBoss 5.1.0 is clearly stricter. This is a good thing, but throwing an error would be useful for stupid people like me!


> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 09:29:57 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Sun, 28 Jun 2009 09:29:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <14081650.1246195797117.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474096#action_12474096 ] 

John Ament commented on JBAS-7032:
----------------------------------

well, upgrading admin console to RF3.3.1 didn't work, and downgrading my apps isn't much of an option as I"m using the layout components.

I also tried to reset the classloader configuration, removing the following from jboss-web.xml in the admin-console

    <class-loading>
        <loader-repository>
            org.jboss.on:loader=embedded
            <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
        </loader-repository>
    </class-loading>

and no such luck.  the application loads now, but an error pops up when i attempt to access it.  this stack trace makes me think that the webbeans manager is somehow messing with seam's conversations.

2009-06-28 09:24:22,070 WARN  [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-1) uncaught exception, passing to exception handler
java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Conversation.instance(Conversation.java:114)
	at org.jboss.seam.faces.FacesManager.prepareBackswitch(FacesManager.java:257)
	at org.jboss.seam.jsf.SeamPhaseListener.afterRenderResponse(SeamPhaseListener.java:505)
	at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:247)
	at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:194)
	at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)
2009-06-28 09:24:22,087 ERROR [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-1) swallowing exception
java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Conversation.instance(Conversation.java:114)
	at org.jboss.seam.faces.FacesManager.prepareBackswitch(FacesManager.java:257)
	at org.jboss.seam.jsf.SeamPhaseListener.afterRenderResponse(SeamPhaseListener.java:505)
	at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:247)
	at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:194)
	at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)
2009-06-28 09:24:27,433 WARN  [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-2) uncaught exception, passing to exception handler
java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Conversation.instance(Conversation.java:114)
	at org.jboss.seam.faces.FacesManager.prepareBackswitch(FacesManager.java:257)
	at org.jboss.seam.jsf.SeamPhaseListener.afterRenderResponse(SeamPhaseListener.java:505)
	at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:247)
	at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:194)
	at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)
2009-06-28 09:24:27,455 ERROR [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-2) swallowing exception
java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Conversation.instance(Conversation.java:114)
	at org.jboss.seam.faces.FacesManager.prepareBackswitch(FacesManager.java:257)
	at org.jboss.seam.jsf.SeamPhaseListener.afterRenderResponse(SeamPhaseListener.java:505)
	at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:247)
	at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:194)
	at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)
2009-06-28 09:24:27,658 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http-127.0.0.1-8080-2) JSF1053: (Listener: org.jboss.webbeans.jsf.WebBeansPhaseListener.afterPhase(), Phase ID: RESTORE_VIEW 1,  View ID: /secure/summary.xhtml) Exception thrown during phase-listener execution: javax.context.ContextNotActiveException: No active contexts for scope type javax.context.RequestScoped
2009-06-28 09:24:27,660 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http-127.0.0.1-8080-2) org.jboss.webbeans.ManagerImpl.getContext(ManagerImpl.java:739)
org.jboss.webbeans.bean.proxy.ClientProxyMethodHandler.getProxiedInstance(ClientProxyMethodHandler.java:116)
org.jboss.webbeans.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:96)
org.jboss.webbeans.servlet.HttpSessionManager_$$_javassist_1.setSession(HttpSessionManager_$$_javassist_1.java)
org.jboss.webbeans.jsf.WebBeansPhaseListener.afterRestoreView(WebBeansPhaseListener.java:119)
org.jboss.webbeans.jsf.WebBeansPhaseListener.afterPhase(WebBeansPhaseListener.java:90)
com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:103)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
java.lang.Thread.run(Thread.java:619)

2009-06-28 09:24:27,686 ERROR [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-2) swallowing exception
javax.el.PropertyNotFoundException: Target Unreachable, identifier 'redirect' resolved to null
	at org.jboss.el.parser.AstValue.getTarget(AstValue.java:38)
	at org.jboss.el.parser.AstValue.invoke(AstValue.java:95)
	at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
	at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
	at org.jboss.seam.core.Events.raiseEvent(Events.java:68)
	at org.jboss.seam.navigation.Pages.notLoggedIn(Pages.java:657)
	at org.jboss.seam.navigation.Pages.redirectToLoginView(Pages.java:572)
	at org.jboss.seam.navigation.Pages.preRender(Pages.java:344)
	at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
	at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
	at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
	at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
	at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)
2009-06-28 09:24:27,725 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http-127.0.0.1-8080-2) JSF1053: (Listener: org.jboss.webbeans.jsf.WebBeansPhaseListener.beforePhase(), Phase ID: RENDER_RESPONSE 6,  View ID: /secure/summary.xhtml) Exception thrown during phase-listener execution: javax.context.ContextNotActiveException: No active contexts for scope type javax.context.RequestScoped
2009-06-28 09:24:27,730 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http-127.0.0.1-8080-2) org.jboss.webbeans.ManagerImpl.getContext(ManagerImpl.java:739)
org.jboss.webbeans.bean.proxy.ClientProxyMethodHandler.getProxiedInstance(ClientProxyMethodHandler.java:116)
org.jboss.webbeans.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:96)
org.jboss.webbeans.conversation.ConversationImpl_$$_javassist_2.isLongRunning(ConversationImpl_$$_javassist_2.java)
org.jboss.webbeans.jsf.WebBeansPhaseListener.beforeRenderReponse(WebBeansPhaseListener.java:71)
org.jboss.webbeans.jsf.WebBeansPhaseListener.beforePhase(WebBeansPhaseListener.java:60)
com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
java.lang.Thread.run(Thread.java:619)

2009-06-28 09:24:27,762 WARN  [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-2) uncaught exception, passing to exception handler
java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Conversation.instance(Conversation.java:114)
	at org.jboss.seam.faces.FacesManager.prepareBackswitch(FacesManager.java:257)
	at org.jboss.seam.jsf.SeamPhaseListener.afterRenderResponse(SeamPhaseListener.java:505)
	at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:247)
	at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:194)
	at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)
2009-06-28 09:24:27,810 ERROR [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-2) swallowing exception
java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Conversation.instance(Conversation.java:114)
	at org.jboss.seam.faces.FacesManager.prepareBackswitch(FacesManager.java:257)
	at org.jboss.seam.jsf.SeamPhaseListener.afterRenderResponse(SeamPhaseListener.java:505)
	at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:247)
	at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:194)
	at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 09:37:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 28 Jun 2009 09:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2145) Trunk
 5.1.0-snapshot hangs if pounded enough
Message-ID: <9231831.1246196276710.JavaMail.jira@cloud.prod.atl2.jboss.com>

Trunk 5.1.0-snapshot hangs if pounded enough
--------------------------------------------

                 Key: JBRULES-2145
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2145
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
    Affects Versions: 5.1.0.M1
         Environment: quad core, ubuntu 9.04
            Reporter: Geoffrey De Smet
            Assignee: Edson Tirelli
            Priority: Critical
             Fix For: 5.1.0.M1


To reproduce:

svn checkout <drools>
edit drools/drools-solver/pom.xml and comment out the dependencies on 5.0.1
(1) run PatientAdmissionScheduleApp in the working directory drools/drools-solver/drools-solver-examples
Click load testdata01.xml
Click solve

In the output, you 'll see something like this:
Trunk is bugged 35/652
Trunk is bugged 36/652
Trunk is bugged 37/652

At some point it might hang before it reaches 652. It does not happen every time, so try again it does reach 652.
I've seen it occur about 1 out of 3 times.

And if it hangs, it really hangs: all 4 of my CPU's are not buzy etc. Definitely a race condition.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 09:42:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 28 Jun 2009 09:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2145) Trunk
 5.1.0-snapshot hangs if pounded enough
In-Reply-To: <9231831.1246196276710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11643175.1246196576506.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474097#action_12474097 ] 

Geoffrey De Smet commented on JBRULES-2145:
-------------------------------------------

cannot reproduce on 5.0.1, so it's only the trunk that is bugged

> Trunk 5.1.0-snapshot hangs if pounded enough
> --------------------------------------------
>
>                 Key: JBRULES-2145
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2145
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.1.0.M1
>         Environment: quad core, ubuntu 9.04
>            Reporter: Geoffrey De Smet
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.1.0.M1
>
>
> To reproduce:
> svn checkout <drools>
> edit drools/drools-solver/pom.xml and comment out the dependencies on 5.0.1
> (1) run PatientAdmissionScheduleApp in the working directory drools/drools-solver/drools-solver-examples
> Click load testdata01.xml
> Click solve
> In the output, you 'll see something like this:
> Trunk is bugged 35/652
> Trunk is bugged 36/652
> Trunk is bugged 37/652
> At some point it might hang before it reaches 652. It does not happen every time, so try again it does reach 652.
> I've seen it occur about 1 out of 3 times.
> And if it hangs, it really hangs: all 4 of my CPU's are not buzy etc. Definitely a race condition.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 09:46:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 28 Jun 2009 09:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2145) Trunk
 5.1.0-snapshot hangs if pounded enough
In-Reply-To: <9231831.1246196276710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3061593.1246196816990.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474098#action_12474098 ] 

Geoffrey De Smet commented on JBRULES-2145:
-------------------------------------------

by depending from drools-solver on mvn repository drools-api/core/compiler timestamped snapshots you might be able to determine which svn commit caused this race condition... otherwise it could be like finding a needle in a haystack

> Trunk 5.1.0-snapshot hangs if pounded enough
> --------------------------------------------
>
>                 Key: JBRULES-2145
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2145
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.1.0.M1
>         Environment: quad core, ubuntu 9.04
>            Reporter: Geoffrey De Smet
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.1.0.M1
>
>
> To reproduce:
> svn checkout <drools>
> edit drools/drools-solver/pom.xml and comment out the dependencies on 5.0.1
> (1) run PatientAdmissionScheduleApp in the working directory drools/drools-solver/drools-solver-examples
> Click load testdata01.xml
> Click solve
> In the output, you 'll see something like this:
> Trunk is bugged 35/652
> Trunk is bugged 36/652
> Trunk is bugged 37/652
> At some point it might hang before it reaches 652. It does not happen every time, so try again it does reach 652.
> I've seen it occur about 1 out of 3 times.
> And if it hangs, it really hangs: all 4 of my CPU's are not buzy etc. Definitely a race condition.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 10:55:57 2009
From: jira-events at lists.jboss.org (Martin Kouba (JIRA))
Date: Sun, 28 Jun 2009 10:55:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6532) TCLFilter doesn't
 work in jboss 5 with war's in any documented way
In-Reply-To: <30315317.1235141804672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19029535.1246200957393.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474099#action_12474099 ] 

Martin Kouba commented on JBAS-6532:
------------------------------------

Actually this patch does not work for me in 5.1.0.GA. Probably because of jboss-logging-log4j was updated to 2.1.0.GA - https://jira.jboss.org/jira/browse/JBAS-6898.

> TCLFilter doesn't work in jboss 5 with war's in any documented way
> ------------------------------------------------------------------
>
>                 Key: JBAS-6532
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6532
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: jdk 6, linux
>            Reporter: robert lazarski
>            Assignee: Scott M Stark
>         Attachments: JBAS-6532.patch, jboss-logging-log4j.jar
>
>
> Reading this doc: 
> http://www.jboss.org/community/docs/DOC-12203
> Indicates a *-exp.war syntax is needed for TCLFilter war use, but there are no files of that type on my system running jboss 5. I've tried all the possible combinations I can think of, posted the problem to the forum, and the result is always that the file sizes and contents of the log files generated are exactly the same for the different war's, ie, no separated content. Here's my current config: 
> <appender name="penguinLog" class="org.apache.log4j.FileAppender">
>       <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler>
>       <param name="Append" value="false"/>
>       <param name="File" value="${jboss.server.home.dir}/log/penguinLog.log"/>
>       <layout class="org.apache.log4j.PatternLayout">
>          <param name="ConversionPattern" value="%d %-5p %c{1} %m%n"/>
>       </layout>
>       <filter class="org.jboss.logging.filter.TCLFilter">
>          <param name="AcceptOnMatch" value="true"/>
>          <param name="DeployURL" value="penguin"/>
>       </filter>
>    </appender>
>    <appender name="wtfLog" class="org.apache.log4j.FileAppender">
>       <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler>
>       <param name="Append" value="false"/>
>       <param name="File" value="${jboss.server.home.dir}/log/wtfLog.log"/>
>       <layout class="org.apache.log4j.PatternLayout">
>          <param name="ConversionPattern" value="%d %-5p %c{1} %m%n"/>
>       </layout>
>       <filter class="org.jboss.logging.filter.TCLFilter">
>          <param name="AcceptOnMatch" value="true"/>
>          <param name="DeployURL" value="wtf-exp.war"/>
>       </filter>
>    </appender>
>    <root>
>       <appender-ref ref="CONSOLE"/>
>       <appender-ref ref="FILE"/>
>       <appender-ref ref="penguinLog"/>
>       <appender-ref ref="wtfLog"/>
>    </root>
> 	

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 11:53:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sun, 28 Jun 2009 11:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1004) GroupRequest: don't
 ignore InterruptedException
Message-ID: <32897668.1246204436416.JavaMail.jira@cloud.prod.atl2.jboss.com>

GroupRequest: don't ignore InterruptedException
-----------------------------------------------

                 Key: JGRP-1004
                 URL: https://jira.jboss.org/jira/browse/JGRP-1004
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 2.6.11, 2.8


[Mircea]

This is related to https://jira.jboss.org/jira/browse/ISPN-38 (Early distributed deadlock detection).
When I determine that a deadlock scenario happens, I try to interrupt a tx originated locally. This translates to an thread.interrupt() call on a thread that is replicating to other caches. The issue is that this call is ignored in jgroups's GroupRequest:
   private boolean collectResponses(long timeout)  {
               .....
               if(timeout > 0) {
                   try {
                       completed.await(timeout, TimeUnit.MILLISECONDS); //LINE 552
                   }
                   catch(Exception e) {
                   }
               }
               ....
  }

So my call to interrupt is ignored (line 552) and the collectResponses method will only return after timeout elapses - not good for me, as I want the method to return immediately if thread is interrupted.
Would it be possible to enhance the code to be aware of interrupt calls? This is in JGroups 2.8.0 Beta2. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 12:13:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sun, 28 Jun 2009 12:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1004) GroupRequest: don't
 ignore InterruptedException
In-Reply-To: <32897668.1246204436416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29290890.1246205636450.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1004.
----------------------------

    Resolution: Done


> GroupRequest: don't ignore InterruptedException
> -----------------------------------------------
>
>                 Key: JGRP-1004
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1004
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.6.11, 2.8
>
>
> [Mircea]
> This is related to https://jira.jboss.org/jira/browse/ISPN-38 (Early distributed deadlock detection).
> When I determine that a deadlock scenario happens, I try to interrupt a tx originated locally. This translates to an thread.interrupt() call on a thread that is replicating to other caches. The issue is that this call is ignored in jgroups's GroupRequest:
>    private boolean collectResponses(long timeout)  {
>                .....
>                if(timeout > 0) {
>                    try {
>                        completed.await(timeout, TimeUnit.MILLISECONDS); //LINE 552
>                    }
>                    catch(Exception e) {
>                    }
>                }
>                ....
>   }
> So my call to interrupt is ignored (line 552) and the collectResponses method will only return after timeout elapses - not good for me, as I want the method to return immediately if thread is interrupted.
> Would it be possible to enhance the code to be aware of interrupt calls? This is in JGroups 2.8.0 Beta2. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 18:47:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 28 Jun 2009 18:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2146) Improved process
 instance migration
Message-ID: <5708418.1246229276798.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improved process instance migration
-----------------------------------

                 Key: JBRULES-2146
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2146
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-core (flow)
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen
             Fix For: 5.1.0.M1


Process instance migration should
 - support new api
 - support nested nodes

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 20:02:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 28 Jun 2009 20:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2146) Improved process
 instance migration
In-Reply-To: <5708418.1246229276798.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32862410.1246233776616.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen resolved JBRULES-2146.
-------------------------------------

    Resolution: Done


> Improved process instance migration
> -----------------------------------
>
>                 Key: JBRULES-2146
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2146
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (flow)
>            Reporter: Kris Verlaenen
>            Assignee: Kris Verlaenen
>             Fix For: 5.1.0.M1
>
>
> Process instance migration should
>  - support new api
>  - support nested nodes

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 20:51:58 2009
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Sun, 28 Jun 2009 20:51:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1000) COMPRESS corrupts
	some messages
In-Reply-To: <7560851.1245854756549.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21566007.1246236718928.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474103#action_12474103 ] 

Dennis Reed commented on JGRP-1000:
-----------------------------------

That makes sense.

With your fix, the buffer size wouldn't have to change.
deflater.getTotalOut() returns the number of bytes written, so if the buffer was too small, it's equal to the buffer size.

So it could be implemented with just:

+    if ( compressed_size < length ) {
         byte[] new_payload=new byte[compressed_size];
         System.arraycopy(compressed_payload, 0, new_payload, 0, compressed_size);
         msg.setBuffer(new_payload); 
         msg.putHeader(name, new CompressHeader(length));
+    }


> COMPRESS corrupts some messages
> -------------------------------
>
>                 Key: JGRP-1000
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1000
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.5
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> COMPRESS.down() stores the compressed message in a temporary buffer the same size as the original message.
> If the compressed size of a message is larger than the original, then part of the message is lost, with no errors reported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 23:30:08 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Sun, 28 Jun 2009 23:30:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1617) JBoss should
 rely on JMSCorrelationID as String as per JMS1.1 spec and handle
 java.lang.UnsupportedOperationException
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9805558.1246246208242.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1617:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> JBoss should rely on JMSCorrelationID as String as per JMS1.1 spec and handle java.lang.UnsupportedOperationException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Sun Jun 28 23:32:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Sun, 28 Jun 2009 23:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1617) JBoss should
 rely on JMSCorrelationID as String as per JMS1.1 spec and handle
 java.lang.UnsupportedOperationException
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10626149.1246246376574.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1617:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> JBoss should rely on JMSCorrelationID as String as per JMS1.1 spec and handle java.lang.UnsupportedOperationException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 02:16:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 29 Jun 2009 02:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1617) JBoss
 should rely on
 JMSCorrelationID as String as per JMS1.1 spec and handle
 java.lang.UnsupportedOperationException
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8711941.1246256216598.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474111#action_12474111 ] 

Howard Gao commented on JBMESSAGING-1617:
-----------------------------------------

As using byte[] as correlation ID is not portable, we can drop it. But if the foreign message has a string correlation ID, it should be preserved.


> JBoss should rely on JMSCorrelationID as String as per JMS1.1 spec and handle java.lang.UnsupportedOperationException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 02:54:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 29 Jun 2009 02:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1664) Ordering
 Group is broken
 on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23330519.1246258496723.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reopened JBMESSAGING-1664:
-------------------------------------



the problem still exists as per the user.

> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 02:54:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 29 Jun 2009 02:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-984) JGroups can not parse
 IPV6 literals in TCPPING protocol configuration
In-Reply-To: <7188979.1242741125294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8605246.1246258496601.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban closed JGRP-984.
-------------------------

    Resolution: Cannot Reproduce Bug


Please reopen with concise instructions as to how to reproduce if this bug still exists

> JGroups can not parse IPV6 literals in TCPPING protocol configuration
> ---------------------------------------------------------------------
>
>                 Key: JGRP-984
>                 URL: https://jira.jboss.org/jira/browse/JGRP-984
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.6
>            Reporter: Brian Stansberry
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> ON JBPAPP-2013 Dominik Pospisil reports the IPv6 address parsing fix in 2.4.6 doesn't handle TCPPING:
> Both
> <TCPPING initial_hosts="::1[7810],fec0::f101:21a:a0ff:fea0:d745[7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> and
> <TCPPING initial_hosts="[::1][7810],[fec0::f101:21a:a0ff:fea0:d745][7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> fails with:
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "::1"
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "fec0::f101:21a:a0ff:fea0:d745"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 02:56:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 29 Jun 2009 02:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-1003) deadlock in TP.send -
 socket write
 hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30246218.1246258616877.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban closed JGRP-1003.
--------------------------

    Resolution: Won't Fix


This should work with use_send_queues="true". Please reopen if not. Note that the entire TCP / TCP_NIO impl will get rewritten once we switch to JDK 1.7 as baseline (NIO2)

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 03:44:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 29 Jun 2009 03:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-924) Shared transport:
 RouterStub cannot connect to 'channel_name'
In-Reply-To: <25276044.1236254962608.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10240132.1246261496883.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474119#action_12474119 ] 

Bela Ban commented on JGRP-924:
-------------------------------

ThreadLocal won't work if message bundling is enabled, because a separate thread (timer thread) might send the bundled messages.

> Shared transport: RouterStub cannot connect to 'channel_name'
> -------------------------------------------------------------
>
>                 Key: JGRP-924
>                 URL: https://jira.jboss.org/jira/browse/JGRP-924
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.8
>
>
> Channel name doesn't mean much in a shared transport. RouterStub.connect(channel_name) won't work

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 04:36:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 29 Jun 2009 04:36:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1617) JBoss
 should rely on
 JMSCorrelationID as String as per JMS1.1 spec and handle
 java.lang.UnsupportedOperationException
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18118681.1246264617062.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474128#action_12474128 ] 

Tim Fox commented on JBMESSAGING-1617:
--------------------------------------

I can't understand what this JIRA is about.. Can someone explain?

> JBoss should rely on JMSCorrelationID as String as per JMS1.1 spec and handle java.lang.UnsupportedOperationException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 04:41:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 29 Jun 2009 04:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1617) JBoss
 should rely on
 JMSCorrelationID as String as per JMS1.1 spec and handle
 java.lang.UnsupportedOperationException
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <811141.1246264916552.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474129#action_12474129 ] 

Tim Fox commented on JBMESSAGING-1617:
--------------------------------------

The description doesn't actually explain what the perceived problem is. I just see a long quote from the JMS spec followed by some talk about a new constructor.

> JBoss should rely on JMSCorrelationID as String as per JMS1.1 spec and handle java.lang.UnsupportedOperationException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 05:13:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 29 Jun 2009 05:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7060) Unable to set
 attributes for MBeans with quoted object name
Message-ID: <18359891.1246266836533.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unable to set attributes for MBeans with quoted object name
-----------------------------------------------------------

                 Key: JBAS-7060
                 URL: https://jira.jboss.org/jira/browse/JBAS-7060
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMX/Web Console
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Jeff Mesnil
            Assignee: Darran Lofthouse


While integration JBoss Messaging 2.0.0.Beta3 to AS 5.1.0.GA, I found an issue when I want to update attributes for one of our MBeans which has a quoted ObjectName. The ObjectName is not properly encoded by the Servlet and an exception is thrown by the MBean registry which claims the mbean is not registered.

The ObjectName is: module=JMS,name="DLQ",type=Queue
  - the *name* value is quoted

When I display this mbean in the jmx console, the corresponding form to update the attributes has a field:

<input type="hidden" name="name" value="org.jboss.messaging:module=JMS,type=Queue,name="DLQ"" /> 

The quotes of the ObjectNames are not properly encoded which results in a bogus object name when applying changes:

0:57:16,082 ERROR [[HtmlAdaptor]] "Servlet.service()" pour la servlet HtmlAdaptor a genere une exception
javax.management.InstanceNotFoundException: org.jboss.messaging:module=JMS,type=Queue,name= is not registered.
	at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:526)
	at org.jboss.mx.server.MBeanServerImpl.getMBeanInfo(MBeanServerImpl.java:675)
	at org.jboss.jmx.adaptor.control.Server.setAttributes(Server.java:172)
	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$5.run(HtmlAdaptorServlet.java:403)
	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$5.run(HtmlAdaptorServlet.java:401)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.setAttributes(HtmlAdaptorServlet.java:399)
	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.updateAttributes(HtmlAdaptorServlet.java:259)
	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:102)
	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:86)

This bug prevents to update many MBeans required to managed properly JBoss Messaging when it is integrated in the AS.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 05:17:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 29 Jun 2009 05:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1672) AS 5 MBean
 Server integration
Message-ID: <32421204.1246267076495.JavaMail.jira@cloud.prod.atl2.jboss.com>

AS 5 MBean Server integration
-----------------------------

                 Key: JBMESSAGING-1672
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1672
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Configuration and Management
    Affects Versions: 2.0.0.beta3
         Environment: JBoss AS 5.1.0.GA
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 2.0.0


When JBoss Messaging is integrated in AS 5, it should use AS 5's MBeanServer instead of the JVM's Platform MBeanServer to ensure JBoss Messaging is manageable through AS 5 jmx-console

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 05:23:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 29 Jun 2009 05:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1617) JBoss
 should rely on
 JMSCorrelationID as String as per JMS1.1 spec and handle
 java.lang.UnsupportedOperationException
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3264983.1246267436615.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474140#action_12474140 ] 

Howard Gao commented on JBMESSAGING-1617:
-----------------------------------------

Hi Tim,

My understanding is that some other providers always throw exception when the set/get JMSCorrelationIDAsBytes get called and the application have to handle the exception whenever a JBossMessage(foreign, id) is constructed. So it suggested we don't use byte[] ID in the constructor as the spec says it may cause portability problem. 

> JBoss should rely on JMSCorrelationID as String as per JMS1.1 spec and handle java.lang.UnsupportedOperationException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 05:38:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 29 Jun 2009 05:38:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1617) JBM does not
 handle
 java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes()
 when copying a foreign message.
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20020094.1246268337314.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1617:
---------------------------------

        Summary: JBM does not handle java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes() when copying a foreign message.  (was: JBoss should rely on JMSCorrelationID as String as per JMS1.1 spec and handle java.lang.UnsupportedOperationException)
    Description: 
Some providers can throw UnsupportedOperationException from getCorrelationIDBytes(). This is called in the foreign message constructor of a JBM message. Currently JBM will fail to copy the message since the exception is not handled.


JavaTM Message Service Specification Version 1.1 :

" 3.4.5 JMSCorrelationID

A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.

JMSCorrelationID can hold one of the following:

? A provider-specific message ID

? An application-specific String

? A provider-native byte[] value

Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.

In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.

If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.

* Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"

So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :

/**
    * A copy constructor for non-JBoss Messaging JMS messages.
    */   
   public JBossMessage(Message foreign, long messageID) throws JMSException
   {
      super(messageID);

      setJMSTimestamp(foreign.getJMSTimestamp());

      try
      {
         byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
         setJMSCorrelationIDAsBytes(corrIDBytes);
      }
      catch(JMSException e)
      {
         // specified as String
         String corrIDString = foreign.getJMSCorrelationID();
         if (corrIDString != null)
         {
            setJMSCorrelationID(corrIDString);
         }
      }
      
      setJMSReplyTo(foreign.getJMSReplyTo());
      setJMSDestination(foreign.getJMSDestination());
      setJMSDeliveryMode(foreign.getJMSDeliveryMode());
      setJMSExpiration(foreign.getJMSExpiration());
      setJMSPriority(foreign.getJMSPriority());
      setJMSType(foreign.getJMSType());

      for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
      {
         String name = (String)props.nextElement();
         
         Object prop = foreign.getObjectProperty(name);

         this.setObjectProperty(name, prop);                       
      }
   }



  was:
JavaTM Message Service Specification Version 1.1 :

" 3.4.5 JMSCorrelationID

A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.

JMSCorrelationID can hold one of the following:

? A provider-specific message ID

? An application-specific String

? A provider-native byte[] value

Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.

In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.

If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.

* Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"

So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :

/**
    * A copy constructor for non-JBoss Messaging JMS messages.
    */   
   public JBossMessage(Message foreign, long messageID) throws JMSException
   {
      super(messageID);

      setJMSTimestamp(foreign.getJMSTimestamp());

      try
      {
         byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
         setJMSCorrelationIDAsBytes(corrIDBytes);
      }
      catch(JMSException e)
      {
         // specified as String
         String corrIDString = foreign.getJMSCorrelationID();
         if (corrIDString != null)
         {
            setJMSCorrelationID(corrIDString);
         }
      }
      
      setJMSReplyTo(foreign.getJMSReplyTo());
      setJMSDestination(foreign.getJMSDestination());
      setJMSDeliveryMode(foreign.getJMSDeliveryMode());
      setJMSExpiration(foreign.getJMSExpiration());
      setJMSPriority(foreign.getJMSPriority());
      setJMSType(foreign.getJMSType());

      for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
      {
         String name = (String)props.nextElement();
         
         Object prop = foreign.getObjectProperty(name);

         this.setObjectProperty(name, prop);                       
      }
   }





I changed the title and added a short description so it's more obvious what this JIRA is about.

> JBM does not handle java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes() when copying a foreign message.
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Some providers can throw UnsupportedOperationException from getCorrelationIDBytes(). This is called in the foreign message constructor of a JBM message. Currently JBM will fail to copy the message since the exception is not handled.
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 07:48:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 29 Jun 2009 07:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1673) MBean
 operations which
 requires a filter should treat an empty string as a null filter
Message-ID: <9927505.1246276136505.JavaMail.jira@cloud.prod.atl2.jboss.com>

MBean operations which requires a filter should treat an empty string as a null filter
--------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1673
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1673
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Configuration and Management
    Affects Versions: 2.0.0.beta3
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 2.0.0


e.g. listMessages requires a filter parameter.

Currently if an empty string is passed, it'll raise an exception when a filter is created from this string.
Instead the MBean should check if the parameter is null or an empty string and treat it as a null filter.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 09:01:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 09:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2147)
 NullPointerException in
 org.drools.rule.builder.PatternBuilder.getDeclarationsMap()
Message-ID: <26204962.1246280516966.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointerException in org.drools.rule.builder.PatternBuilder.getDeclarationsMap()
-----------------------------------------------------------------------------------

                 Key: JBRULES-2147
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2147
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler (expert)
    Affects Versions: 5.0.1.FINAL
         Environment: java 1.5, linux x64, jboss 4.0.5
            Reporter: Juergen none
            Assignee: Mark Proctor


I understand my rules/fact objects might not be proper (still searching), but resulting in a NullPointerException is not proper as well

entry.getValue().getExtractor().getExtractToClass() yields NullPointerException, because entry.getValue().getExtractor() is null

eclipse debug variable:

value	org.drools.rule.Declaration  (id=502)	
	identifier	"schoolForm" (id=501)	
	internalFact	false	
	pattern	org.drools.rule.Pattern  (id=508)	
		behaviors	null	
		constraints	java.util.ArrayList<E>  (id=520)	
		declaration	org.drools.rule.Declaration  (id=521)	
		declarations	java.util.HashMap<K,V>  (id=522)	
		index	1	
		objectType	org.drools.base.ClassObjectType  (id=524)	
		offset	0	
		source	null	
	readAccessor	null	

Stacktrace:
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
...
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException
        at org.drools.rule.builder.PatternBuilder.getDeclarationsMap(PatternBuilder.java:641)
        at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:574)
        at org.drools.rule.builder.PatternBuilder.buildConstraint(PatternBuilder.java:244)
        at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:196)
        at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:104)
        at org.drools.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:69)
        at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:68)
        at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:1159)
        at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:649)
        at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:278)
        at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:158)
        at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:93)
...


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 09:18:57 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Mon, 29 Jun 2009 09:18:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-985) Flush and join
 problems during constant node failures and constant joins
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17461343.1246281537030.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic updated JGRP-985:
-------------------------------------

    Summary: Flush and join problems during constant node failures and constant joins  (was: Admin  Join problem -GMS flush by coordinator failed)


> Flush and join problems during constant node failures and constant joins
> ------------------------------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 09:22:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 09:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2147)
 NullPointerException in
 org.drools.rule.builder.PatternBuilder.getDeclarationsMap()
In-Reply-To: <26204962.1246280516966.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21056488.1246281776577.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474167#action_12474167 ] 

Juergen none commented on JBRULES-2147:
---------------------------------------

was a type: attribute name was schoolType, not schoolForm
no NullPointerException after replacing
still, could be better handled

> NullPointerException in org.drools.rule.builder.PatternBuilder.getDeclarationsMap()
> -----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2147
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2147
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.0.1.FINAL
>         Environment: java 1.5, linux x64, jboss 4.0.5
>            Reporter: Juergen none
>            Assignee: Mark Proctor
>
> I understand my rules/fact objects might not be proper (still searching), but resulting in a NullPointerException is not proper as well
> entry.getValue().getExtractor().getExtractToClass() yields NullPointerException, because entry.getValue().getExtractor() is null
> eclipse debug variable:
> value	org.drools.rule.Declaration  (id=502)	
> 	identifier	"schoolForm" (id=501)	
> 	internalFact	false	
> 	pattern	org.drools.rule.Pattern  (id=508)	
> 		behaviors	null	
> 		constraints	java.util.ArrayList<E>  (id=520)	
> 		declaration	org.drools.rule.Declaration  (id=521)	
> 		declarations	java.util.HashMap<K,V>  (id=522)	
> 		index	1	
> 		objectType	org.drools.base.ClassObjectType  (id=524)	
> 		offset	0	
> 		source	null	
> 	readAccessor	null	
> Stacktrace:
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
> ...
>         at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.NullPointerException
>         at org.drools.rule.builder.PatternBuilder.getDeclarationsMap(PatternBuilder.java:641)
>         at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:574)
>         at org.drools.rule.builder.PatternBuilder.buildConstraint(PatternBuilder.java:244)
>         at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:196)
>         at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:104)
>         at org.drools.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:69)
>         at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:68)
>         at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:1159)
>         at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:649)
>         at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:278)
>         at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:158)
>         at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:93)
> ...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 09:43:56 2009
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Mon, 29 Jun 2009 09:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-2389) Preferences
 values are not getting replicated in clustered setup
In-Reply-To: <12697615.1241691166584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10139836.1246283036808.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Putz resolved JBPORTAL-2389.
-----------------------------------

    Fix Version/s: 2.7.3 Final
       Resolution: Done


> Preferences values are not getting replicated in clustered setup
> ----------------------------------------------------------------
>
>                 Key: JBPORTAL-2389
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2389
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.7.2 Final
>         Environment: two clustered instances with a shared database
>            Reporter: Martin Putz
>            Assignee: Martin Putz
>             Fix For: 2.7.3 Final
>
>         Attachments: SimplestHelloWorldWithPreferences.zip
>
>
> Any change in portlet preferences on one of the servers (using Admin Portal) is not getting reflected on the other cluster nodes. 
> Steps to replicate this is:
> 1. Develop a portlet with some preferences (Note: an extended version of the SimplestHelloWorldPortlet is attached)
> 2. Deploy the portlet war on 2 nodes running under cluster.
> 3. Use SERVER1 to change the preference value
> 4. Hit SERVER1 to see that portlet and preferences value printed on stdout.
> 5. Hit SERVER2 and verify the preferences. This will print old value.
> 6. Change the same preference on SERVER2 and see StaleStateException.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 09:43:56 2009
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Mon, 29 Jun 2009 09:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-2389) Preferences
 values are not getting replicated in clustered setup
In-Reply-To: <12697615.1241691166584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12293019.1246283036633.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Putz reassigned JBPORTAL-2389:
-------------------------------------

    Assignee: Martin Putz  (was: Thomas Heute)


> Preferences values are not getting replicated in clustered setup
> ----------------------------------------------------------------
>
>                 Key: JBPORTAL-2389
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2389
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.7.2 Final
>         Environment: two clustered instances with a shared database
>            Reporter: Martin Putz
>            Assignee: Martin Putz
>             Fix For: 2.7.3 Final
>
>         Attachments: SimplestHelloWorldWithPreferences.zip
>
>
> Any change in portlet preferences on one of the servers (using Admin Portal) is not getting reflected on the other cluster nodes. 
> Steps to replicate this is:
> 1. Develop a portlet with some preferences (Note: an extended version of the SimplestHelloWorldPortlet is attached)
> 2. Deploy the portlet war on 2 nodes running under cluster.
> 3. Use SERVER1 to change the preference value
> 4. Hit SERVER1 to see that portlet and preferences value printed on stdout.
> 5. Hit SERVER2 and verify the preferences. This will print old value.
> 6. Change the same preference on SERVER2 and see StaleStateException.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:07:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 29 Jun 2009 10:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1617) JBM does not
 handle
 java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes()
 when copying a foreign message.
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25759094.1246284476766.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1617.
-----------------------------------



done

> JBM does not handle java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes() when copying a foreign message.
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Some providers can throw UnsupportedOperationException from getCorrelationIDBytes(). This is called in the foreign message constructor of a JBM message. Currently JBM will fail to copy the message since the exception is not handled.
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 10:10:58 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 29 Jun 2009 10:10:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7061) Upgrade EJB3 to 1.1.8
Message-ID: <15406494.1246284658866.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade EJB3 to 1.1.8
---------------------

                 Key: JBAS-7061
                 URL: https://jira.jboss.org/jira/browse/JBAS-7061
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
          Components: EJB3
            Reporter: jaikiran pai
            Assignee: jaikiran pai
             Fix For: JBossAS-5.2.0.Beta1


Upgrade to the latest released EJB3 1.1.8 version.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:10:59 2009
From: jira-events at lists.jboss.org (Oleg Stepanov (JIRA))
Date: Mon, 29 Jun 2009 10:10:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7062) Number of options
 and behaviour
 of login modules should be extended to allow complex login configurations
Message-ID: <28228803.1246284659542.JavaMail.jira@cloud.prod.atl2.jboss.com>

Number of options and behaviour of login modules should be extended to allow complex login configurations

-----------------------------------------------------------------------------------------------------------

                 Key: JBAS-7062
                 URL: https://jira.jboss.org/jira/browse/JBAS-7062
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA, JBossAS-4.2.3.GA, JBossAS-4.2.2.GA
         Environment: OS: Windows XP, JDK: Sun 1.6.0 Update 10, JBoss AS: 4.2.2.GA
            Reporter: Oleg Stepanov
            Assignee: Anil Saldhana
            Priority: Optional


With the current AbstractLoginModule/UsernamePasswordLoginModule design (which all the rest modules are sublcasses of) it is impossible to compose complex login configurations.
Consider the following scenario: there are two authentication subsystems, the database and LDAP. Let's say that database stores passwords being SHA1 hashed while LDAP instance uses MD5. For this case we could have used the following (for now yet imaginary) configuration of login modules:
0. ClientLoginModule. Used on the client side to push credentials into SecurityAssociations for passing along with EJB calls.
1. DatabaseServerLoginModule with SHA1 hash option and sufficient flag
2. ModifyPasswordLoginModule (subclass of UsernamePasswordLoginModule) that a) hashes password, b) adds {scheme} prefix to the hashed password as required by the section 5.3 of RFC2307 and c) stores the resulting password in the shared state accessible by the following modules.
3. LdapLoginModule with required flag and (at least the guess would be) the useFirstPass option.

With the current implementation it won't work. If we use useFirstPass option for any module and it finds shared credentials then no actual login is ever performed. Moreover, there's no way to tell the specific module that credentials should be taken from a callback handler but still stored in the shared state (or vice versa).

Proposed is to add more options to affect a login module's behavior:
* useInternalPass - if set to true, the module will try to use credentials stored under private keys in the sharedState instead of useFirstPass keys
* saveSharedPass - if true, the resulting credentials will be stored under javax.security.auth.login.name and javax.security.auth.login.password keys in the sharedState map.
* saveInternalPass - if true, the resulting credentials will be stored under private keys in the sharedState map (independently of useFirstPass flag).
* forceLogin - if true, the module will attempt to perform the login operation even if credentials were read from the sharedState.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:12:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 29 Jun 2009 10:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7063) Upgrade EJB3 to 1.1.8
Message-ID: <31881366.1246284776868.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade EJB3 to 1.1.8
---------------------

                 Key: JBAS-7063
                 URL: https://jira.jboss.org/jira/browse/JBAS-7063
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
            Reporter: jaikiran pai
            Assignee: jaikiran pai
             Fix For: JBossAS-6.0.0.Alpha1


Upgrade to the latest released EJB3 1.1.8 version.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:12:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 29 Jun 2009 10:12:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6934) Tests in
 org.jboss.test.cluster failing with IBM JDK 1.5 - Failed to start
 cluster/http/jboss-web-test-service.xml
In-Reply-To: <23484241.1242648377491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <79473.1246284777633.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6934.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> Tests in org.jboss.test.cluster failing with IBM JDK 1.5 - Failed to start cluster/http/jboss-web-test-service.xml
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6934
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6934
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Some clustered tests are failing with this error message:
> Failed to start cluster/http/jboss-web-test-service.xml
> org.jboss.cache.pojo.PojoCacheException: Failed to start cluster/http/jboss-web-test-service.xml
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.<init>(PojoCacheImpl.java:63)
> 	at org.jboss.cache.pojo.PojoCacheFactory.createCache(PojoCacheFactory.java:42)
> 	at org.jboss.test.cluster.testutil.SessionTestUtil.getConfiguration(SessionTestUtil.java:147)
> 	at org.jboss.test.cluster.testutil.SessionTestUtil.createCache(SessionTestUtil.java:136)
> 	at org.jboss.test.cluster.testutil.CacheConfigTestSetup.setUp(CacheConfigTestSetup.java:84)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: org.jboss.cache.config.ConfigurationException: Unable to build interceptor chain
> 	at org.jboss.cache.factories.InterceptorChainFactory.construct(InterceptorChainFactory.java:229)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:318)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.DefaultCacheFactory.bootstrap(DefaultCacheFactory.java:155)
> 	at org.jboss.cache.DefaultCacheFactory.createAndWire(DefaultCacheFactory.java:141)
> 	at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:120)
> 	at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:93)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.<init>(PojoCacheImpl.java:58)
> Caused by: java.lang.TypeNotPresentException: Type net.jcip.annotations.ThreadSafe not present
> 	at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:38)
> 	at com.ibm.oti.reflect.AnnotationHelper.getDeclaredAnnotations(AnnotationHelper.java:50)
> 	at java.lang.Class.getDeclaredAnnotations(Class.java:1620)
> 	at java.lang.Class.getAnnotations(Class.java:1581)
> 	at java.lang.Class.getAnnotation(Class.java:1561)
> 	at java.lang.Class.isAnnotationPresent(Class.java:1648)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:252)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.InterceptorChainFactory.createInterceptor(InterceptorChainFactory.java:60)
> 	at org.jboss.cache.factories.InterceptorChainFactory.buildInterceptorChain(InterceptorChainFactory.java:75)
> 	at org.jboss.cache.factories.InterceptorChainFactory.construct(InterceptorChainFactory.java:225)
> Caused by: java.lang.ClassNotFoundException: net.jcip.annotations.ThreadSafe
> 	at java.lang.Class.forName(Class.java:163)
> 	at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:33)
> This is the list of the tests failing because of this: 
> org.jboss.test.cluster.defaultcfg.simpleweb.test.AttributeBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.BuddyReplicationFailoverUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.BuddyReplicationToPassivatedSessionUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.ClusteredSessionNotificationPolicyTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.FieldBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.JBossCacheManagerConfigurationUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.ReplicationToPassivatedSessionUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionCountUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionExpirationUnitTestCase
> In total it causes 29 failures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:12:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 29 Jun 2009 10:12:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6962)
 org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
In-Reply-To: <994948.1242838745393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15872190.1246284777917.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6962.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
> ----------------------------------------------------------------------
>
>                 Key: JBAS-6962
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6962
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: TEST-org.jboss.test.cmp2.commerce.CompleteUnitTestCase.xml
>
>
> With IBM JDK 1.6 the test testJBossQL fails with this message:
> Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> junit.framework.AssertionFailedError: Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> 	at org.jboss.test.cmp2.commerce.QueryTest.testJBossQL(QueryTest.java:169)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)
> It's strange that with IBM 1.6 the failure does not happen in that test, but in different - testEJBQL:
> expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> junit.framework.ComparisonFailure: expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> 	at org.jboss.test.cmp2.commerce.QueryTest.testEJBQL(QueryTest.java:329)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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:193)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 10:14:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 29 Jun 2009 10:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6968)
 org.jboss.test.spring.test.SpringClusterTestCase failing with IBM JDK 1.5
In-Reply-To: <32698421.1243001398195.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1935507.1246284896775.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6968.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> org.jboss.test.spring.test.SpringClusterTestCase failing with IBM JDK 1.5
> -------------------------------------------------------------------------
>
>                 Key: JBAS-6968
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6968
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: spring-server.log
>
>
> org.jboss.test.spring.test.SpringClusterTestCase is failing with this message:
> testStandalone	Failure	N/A
> junit.framework.AssertionFailedError
> 	at org.jboss.test.spring.test.SpringClusterTestCase.testStandalone(SpringClusterTestCase.java:43)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> In the server log you can see:
> ...
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/lib/spring-cluster-pojos.jar/" is in error due to the following reason(s): java.lang.ClassNotFoundException: net.jcip.annotations.ThreadSafe
> ...
> Which shows that it is again the same problem with net.jcip.annotations.ThreadSafe missing in IBM JDK as discussed here JBAS-6934 and JBAS-6428.
> Solution: Ensure that jcip-annotations.jar gets copied to server/springdeployer/lib/ when the config is created.
> A. Add jcip-annotations.jar to server/default/lib (it is 2.6 KB) - springdeployer is created out of default
> B. Change testsuite/build.xml to make ant copy jcip-annotations.jar from server/all/lib/ to server/springdeployer/lib/ - don't know how to do that easily
> A. seems easier to do.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:14:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 29 Jun 2009 10:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6967)
 org.jboss.test.security.test.HttpsUnitTestCase failing with IBM JDK
In-Reply-To: <27953188.1242999477645.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7957651.1246284897013.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6967.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> org.jboss.test.security.test.HttpsUnitTestCase failing with IBM JDK
> -------------------------------------------------------------------
>
>                 Key: JBAS-6967
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6967
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: TEST-org.jboss.test.security.test.HttpsUnitTestCase-tests-security-basic-unit.xml
>
>
> When running the AS testsuite, this test case shows an error:
> org.jboss.test.security.test.HttpsUnitTestCase
> The error message is:
> unknown	Error	N/A
> java.lang.NullPointerException
> 	at java.security.Security.insertProviderAt(Security.java:357)
> 	at java.security.Security.addProvider(Security.java:406)
> 	at org.jboss.test.security.test.HttpsUnitTestCase$1.setUp(HttpsUnitTestCase.java:171)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> When you look in the source code, this is the line where it fails:
> Security.addProvider(SecurityProviderUtil.getJSSEProvider());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:14:57 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 29 Jun 2009 10:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1859) core tests:
 container lookups should be done after all containers are registered
Message-ID: <32556428.1246284897155.JavaMail.jira@cloud.prod.atl2.jboss.com>

core tests: container lookups should be done after all containers are registered
--------------------------------------------------------------------------------

                 Key: EJBTHREE-1859
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1859
             Project: EJB 3.0
          Issue Type: Bug
          Components: core
    Affects Versions: 1.1.8
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: 1.1.9


AbstractEJB3TestCase in registerContainer shouldn't check whether the container can be looked up. Instead, all the containers from the deployment module should be registered first. So, the lookup check should be moved up to deploySessionEjbs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:16:57 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 29 Jun 2009 10:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1859) core tests:
 container lookups should be done after all containers are registered
In-Reply-To: <32556428.1246284897155.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28729018.1246285017095.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved EJBTHREE-1859.
-----------------------------------------

    Resolution: Done


Done.

> core tests: container lookups should be done after all containers are registered
> --------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1859
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1859
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.8
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.1.9
>
>
> AbstractEJB3TestCase in registerContainer shouldn't check whether the container can be looked up. Instead, all the containers from the deployment module should be registered first. So, the lookup check should be moved up to deploySessionEjbs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:16:57 2009
From: jira-events at lists.jboss.org (Oleg Stepanov (JIRA))
Date: Mon, 29 Jun 2009 10:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7062) Number of options
 and behaviour
 of login modules should be extended to allow complex login configurations
In-Reply-To: <28228803.1246284659542.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <391537.1246285017476.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Stepanov updated JBAS-7062:
--------------------------------

    Attachment: modified_modules.zip


Here's the archive with modified AbstractServerLoginModule and UsernamePasswordLoginModule. The first contains methods for parsing the additional options and accessing the shared states, the second has its login method modified according to the proposed behaviour.

I believe these modifications won't affect any configurations with the new options being not specified.

> Number of options and behaviour of login modules should be extended to allow complex login configurations

> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7062
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7062
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.3.GA, JBossAS-5.1.0.GA
>         Environment: OS: Windows XP, JDK: Sun 1.6.0 Update 10, JBoss AS: 4.2.2.GA
>            Reporter: Oleg Stepanov
>            Assignee: Anil Saldhana
>            Priority: Optional
>         Attachments: modified_modules.zip
>
>
> With the current AbstractLoginModule/UsernamePasswordLoginModule design (which all the rest modules are sublcasses of) it is impossible to compose complex login configurations.
> Consider the following scenario: there are two authentication subsystems, the database and LDAP. Let's say that database stores passwords being SHA1 hashed while LDAP instance uses MD5. For this case we could have used the following (for now yet imaginary) configuration of login modules:
> 0. ClientLoginModule. Used on the client side to push credentials into SecurityAssociations for passing along with EJB calls.
> 1. DatabaseServerLoginModule with SHA1 hash option and sufficient flag
> 2. ModifyPasswordLoginModule (subclass of UsernamePasswordLoginModule) that a) hashes password, b) adds {scheme} prefix to the hashed password as required by the section 5.3 of RFC2307 and c) stores the resulting password in the shared state accessible by the following modules.
> 3. LdapLoginModule with required flag and (at least the guess would be) the useFirstPass option.
> With the current implementation it won't work. If we use useFirstPass option for any module and it finds shared credentials then no actual login is ever performed. Moreover, there's no way to tell the specific module that credentials should be taken from a callback handler but still stored in the shared state (or vice versa).
> Proposed is to add more options to affect a login module's behavior:
> * useInternalPass - if set to true, the module will try to use credentials stored under private keys in the sharedState instead of useFirstPass keys
> * saveSharedPass - if true, the resulting credentials will be stored under javax.security.auth.login.name and javax.security.auth.login.password keys in the sharedState map.
> * saveInternalPass - if true, the resulting credentials will be stored under private keys in the sharedState map (independently of useFirstPass flag).
> * forceLogin - if true, the module will attempt to perform the login operation even if credentials were read from the sharedState.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:32:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 29 Jun 2009 10:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1617) JBM does not
 handle
 java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes()
 when copying a foreign message.
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12465325.1246285976668.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reopened JBMESSAGING-1617:
-------------------------------------



Reopen because it drops an existing functionality and will cause backward compatibility issue.

> JBM does not handle java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes() when copying a foreign message.
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Some providers can throw UnsupportedOperationException from getCorrelationIDBytes(). This is called in the foreign message constructor of a JBM message. Currently JBM will fail to copy the message since the exception is not handled.
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 11:06:56 2009
From: jira-events at lists.jboss.org (Enrico Schenk (JIRA))
Date: Mon, 29 Jun 2009 11:06:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7064) Improve CMP mapping
	for Ingres
Message-ID: <4153775.1246288016864.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve CMP mapping for Ingres
------------------------------

                 Key: JBAS-7064
                 URL: https://jira.jboss.org/jira/browse/JBAS-7064
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: CMP service
            Reporter: Enrico Schenk
            Assignee: Alexey Loubyansky
            Priority: Minor


Improve support for the Ingres database system in the CMP service. This requires an update to the Ingres data type and function mapping in the file standardjbosscmp-jdbc.xml.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 11:10:56 2009
From: jira-events at lists.jboss.org (Enrico Schenk (JIRA))
Date: Mon, 29 Jun 2009 11:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7064) Improve CMP mapping
	for Ingres
In-Reply-To: <4153775.1246288016864.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8053220.1246288256495.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Enrico Schenk updated JBAS-7064:
--------------------------------

    Attachment: standardjbosscmp-jdbc.xml


The attached standardjbosscmp-jdbc.xml contains an updated type mapping section for Ingres.

> Improve CMP mapping for Ingres
> ------------------------------
>
>                 Key: JBAS-7064
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7064
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>            Reporter: Enrico Schenk
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>         Attachments: standardjbosscmp-jdbc.xml
>
>
> Improve support for the Ingres database system in the CMP service. This requires an update to the Ingres data type and function mapping in the file standardjbosscmp-jdbc.xml.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 11:48:09 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 29 Jun 2009 11:48:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-73) JUnit 4.6
In-Reply-To: <10026065.1236869962567.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13969962.1246290489437.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-73:
---------------------------------

    Summary: JUnit 4.6  (was: JUnit 4.5)


> JUnit 4.6
> ---------
>
>                 Key: JBJCA-73
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-73
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha1
>
>
> Test

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 12:28:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 12:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2148) make jsr94
 StatefulRuleSession keepReference configurable, not constant true
Message-ID: <16725628.1246292937006.JavaMail.jira@cloud.prod.atl2.jboss.com>

make jsr94 StatefulRuleSession keepReference configurable, not constant true
----------------------------------------------------------------------------

                 Key: JBRULES-2148
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2148
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-jsr94
    Affects Versions: 5.0.1.FINAL
            Reporter: Juergen none
            Assignee: Mark Proctor


I use stateful rule session via jsr94
i configured keepReference=false via properties file, but org.drools.jsr94.rules.StatefulRuleSessionImpl hardcoded changes it to true
org.drools.jsr94.rules.StatefulRuleSessionImpl.java::114:
conf.setKeepReference( true );

hard to call release(), via session invalidation or object finalization
I simply would like for drools not to keep a reference, something jsr94 api impl does not allow me to do

patched 4.0.7, will have to do it again for 5.0.1.FINAL

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 12:35:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 12:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2148) make jsr94
 StatefulRuleSession keepReference configurable, not constant true
In-Reply-To: <16725628.1246292937006.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14147031.1246293356555.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474222#action_12474222 ] 

Juergen none commented on JBRULES-2148:
---------------------------------------

sorry for duplicate, forgot I already created an issue for 4.0.7

> make jsr94 StatefulRuleSession keepReference configurable, not constant true
> ----------------------------------------------------------------------------
>
>                 Key: JBRULES-2148
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2148
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-jsr94
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Juergen none
>            Assignee: Mark Proctor
>
> I use stateful rule session via jsr94
> i configured keepReference=false via properties file, but org.drools.jsr94.rules.StatefulRuleSessionImpl hardcoded changes it to true
> org.drools.jsr94.rules.StatefulRuleSessionImpl.java::114:
> conf.setKeepReference( true );
> hard to call release(), via session invalidation or object finalization
> I simply would like for drools not to keep a reference, something jsr94 api impl does not allow me to do
> patched 4.0.7, will have to do it again for 5.0.1.FINAL

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 12:40:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 12:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2148) make jsr94
 StatefulRuleSession keepReference configurable, not constant true
In-Reply-To: <16725628.1246292937006.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20946399.1246293656813.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen none closed JBRULES-2148.
---------------------------------



> make jsr94 StatefulRuleSession keepReference configurable, not constant true
> ----------------------------------------------------------------------------
>
>                 Key: JBRULES-2148
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2148
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-jsr94
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Juergen none
>            Assignee: Mark Proctor
>
> I use stateful rule session via jsr94
> i configured keepReference=false via properties file, but org.drools.jsr94.rules.StatefulRuleSessionImpl hardcoded changes it to true
> org.drools.jsr94.rules.StatefulRuleSessionImpl.java::114:
> conf.setKeepReference( true );
> hard to call release(), via session invalidation or object finalization
> I simply would like for drools not to keep a reference, something jsr94 api impl does not allow me to do
> patched 4.0.7, will have to do it again for 5.0.1.FINAL

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 12:40:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 12:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2148) make jsr94
 StatefulRuleSession keepReference configurable, not constant true
In-Reply-To: <16725628.1246292937006.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1249318.1246293656639.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen none resolved JBRULES-2148.
-----------------------------------

    Resolution: Duplicate Issue


> make jsr94 StatefulRuleSession keepReference configurable, not constant true
> ----------------------------------------------------------------------------
>
>                 Key: JBRULES-2148
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2148
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-jsr94
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Juergen none
>            Assignee: Mark Proctor
>
> I use stateful rule session via jsr94
> i configured keepReference=false via properties file, but org.drools.jsr94.rules.StatefulRuleSessionImpl hardcoded changes it to true
> org.drools.jsr94.rules.StatefulRuleSessionImpl.java::114:
> conf.setKeepReference( true );
> hard to call release(), via session invalidation or object finalization
> I simply would like for drools not to keep a reference, something jsr94 api impl does not allow me to do
> patched 4.0.7, will have to do it again for 5.0.1.FINAL

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 12:56:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 12:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1168) jsr94,
 create stateful rule session, allow to set keepReference
In-Reply-To: <28027509.1188917712150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9995287.1246294616930.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen none updated JBRULES-1168:
----------------------------------

    Attachment: StatefulRuleSessionImpl.java


patched v5.0.1.FINAL org.drools.jsr94.rules.StatefulRuleSessionImpl.java I will probably use

> jsr94, create stateful rule session, allow to set keepReference
> ---------------------------------------------------------------
>
>                 Key: JBRULES-1168
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1168
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-jsr94
>    Affects Versions: 4.0.1, 5.0.1.FINAL
>            Reporter: Juergen none
>            Assignee: Mark Proctor
>            Priority: Minor
>         Attachments: StatefulRuleSessionImpl.java
>
>
> org.drools.jsr94.rules.StatefulRuleSessionImpl currently calls initSession() with constant value true for keepReference. Would be nice if this could be configurable via properties map.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 12:56:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 12:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1168) jsr94,
 create stateful rule session, allow to set keepReference
In-Reply-To: <28027509.1188917712150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <993756.1246294616744.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen none updated JBRULES-1168:
----------------------------------

    Affects Version/s: 5.0.1.FINAL


> jsr94, create stateful rule session, allow to set keepReference
> ---------------------------------------------------------------
>
>                 Key: JBRULES-1168
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1168
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-jsr94
>    Affects Versions: 4.0.1, 5.0.1.FINAL
>            Reporter: Juergen none
>            Assignee: Mark Proctor
>            Priority: Minor
>         Attachments: StatefulRuleSessionImpl.java
>
>
> org.drools.jsr94.rules.StatefulRuleSessionImpl currently calls initSession() with constant value true for keepReference. Would be nice if this could be configurable via properties map.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 14:45:56 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 29 Jun 2009 14:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7065) Debugging security
	manager
Message-ID: <14252172.1246301156640.JavaMail.jira@cloud.prod.atl2.jboss.com>

Debugging security manager
--------------------------

                 Key: JBAS-7065
                 URL: https://jira.jboss.org/jira/browse/JBAS-7065
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
            Reporter: David Lloyd
            Assignee: David Lloyd
            Priority: Minor
             Fix For: JBossAS-6.0.0.Alpha1


Develop a security manager which logs security violations, which is surprisingly difficult to make the default security manager do.

If the server log is used, care must be taken to prevent excessive recursion caused by access violations triggered while logging.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 14:45:56 2009
From: jira-events at lists.jboss.org (Tobias Frech (JIRA))
Date: Mon, 29 Jun 2009 14:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7066) Unicode characters
 in the install path prevent the server from starting
Message-ID: <23369825.1246301157010.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unicode characters in the install path prevent the server from starting
-----------------------------------------------------------------------

                 Key: JBAS-7066
                 URL: https://jira.jboss.org/jira/browse/JBAS-7066
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA, JBossAS-4.2.3.GA
         Environment: Linux fedora.localdomain 2.6.27.24-78.2.53.fc9.i686 #1 SMP Wed May 20 23:51:32 EDT 2009 i686 i686 i386 GNU/Linux

            Reporter: Tobias Frech


When trying to start JBoss from a path that contains Unicode characters the server fails to boot at all.
JBoss 4.2.3 throws an Exception with "ERROR: it turns out the root cause is not always a runtime exception!" from org.jboss.mx.server.MBeanServerImpl.
JBoss 5.1.0 is a bit better:

20:31:25,313 ERROR [AbstractKernelController] Error installing to Instantiated: name=TransactionManager state=Described
java.lang.ExceptionInInitializerError: java.net.MalformedURLException: no protocol: /home/tobi/Vortr?ge/jboss-5.1.0.GA/server/default/conf/jbossts-properties.xml
	at com.arjuna.ats.arjuna.common.arjPropertyManager.<clinit>(arjPropertyManager.java:70)
	at com.arjuna.ats.jbossatx.jta.TransactionManagerService.<clinit>(TransactionManagerService.java:110)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:149)
...


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 14:45:57 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 29 Jun 2009 14:45:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7065) Debugging security
	manager
In-Reply-To: <14252172.1246301156640.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2800492.1246301157169.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474237#action_12474237 ] 

David Lloyd commented on JBAS-7065:
-----------------------------------

Maybe add a boot option --security-debug or something like that which automatically sets up the appropriate security manager.

Also, the log messages should include not only a stack trace of the failed operation, but also the stack of codesources that were checked.

> Debugging security manager
> --------------------------
>
>                 Key: JBAS-7065
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7065
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>            Priority: Minor
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Develop a security manager which logs security violations, which is surprisingly difficult to make the default security manager do.
> If the server log is used, care must be taken to prevent excessive recursion caused by access violations triggered while logging.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 18:32:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 29 Jun 2009 18:32:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2149)
 ClassNotFoundException when deserializing a session with accumulate
Message-ID: <14229714.1246314777014.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClassNotFoundException when deserializing a session with accumulate
-------------------------------------------------------------------

                 Key: JBRULES-2149
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2149
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


package org.drools

import java.util.List

global List results

rule "test accumulate serialization"
when
    $total : List() from accumulate( 
         $c : Cheese( type == "brie" ),
         init( java.util.ArrayList s = new java.util.ArrayList(); ),
         action( s.add($c); ),
         reverse( s.remove($c); ),
         result( s ) )
then
    results.add( $total );
end




java.lang.ClassNotFoundException: org.drools.Rule_test_accumulate_serialization_0$Accumulate0
	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:306)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:242)
	at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:585)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
	at org.drools.marshalling.impl.InputMarshaller.readLeftTuple(InputMarshaller.java:540)
	at org.drools.marshalling.impl.InputMarshaller.readFactHandles(InputMarshaller.java:345)
	at org.drools.marshalling.impl.InputMarshaller.readSession(InputMarshaller.java:207)
	at org.drools.marshalling.impl.DefaultMarshaller.unmarshall(DefaultMarshaller.java:75)
	at org.drools.marshalling.impl.DefaultMarshaller.unmarshall(DefaultMarshaller.java:47)
	at org.drools.integrationtests.MarshallingTest.testAccumulateSerialization(MarshallingTest.java:2290)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 18:36:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 29 Jun 2009 18:36:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2149)
 ClassNotFoundException when deserializing a session with accumulate
In-Reply-To: <14229714.1246314777014.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4563122.1246315017009.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2149.
----------------------------------

    Resolution: Done


> ClassNotFoundException when deserializing a session with accumulate
> -------------------------------------------------------------------
>
>                 Key: JBRULES-2149
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2149
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> package org.drools
> import java.util.List
> global List results
> rule "test accumulate serialization"
> when
>     $total : List() from accumulate( 
>          $c : Cheese( type == "brie" ),
>          init( java.util.ArrayList s = new java.util.ArrayList(); ),
>          action( s.add($c); ),
>          reverse( s.remove($c); ),
>          result( s ) )
> then
>     results.add( $total );
> end
> java.lang.ClassNotFoundException: org.drools.Rule_test_accumulate_serialization_0$Accumulate0
> 	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:306)
> 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:242)
> 	at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:585)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
> 	at org.drools.marshalling.impl.InputMarshaller.readLeftTuple(InputMarshaller.java:540)
> 	at org.drools.marshalling.impl.InputMarshaller.readFactHandles(InputMarshaller.java:345)
> 	at org.drools.marshalling.impl.InputMarshaller.readSession(InputMarshaller.java:207)
> 	at org.drools.marshalling.impl.DefaultMarshaller.unmarshall(DefaultMarshaller.java:75)
> 	at org.drools.marshalling.impl.DefaultMarshaller.unmarshall(DefaultMarshaller.java:47)
> 	at org.drools.integrationtests.MarshallingTest.testAccumulateSerialization(MarshallingTest.java:2290)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at junit.framework.TestCase.runTest(TestCase.java:154)
> 	at junit.framework.TestCase.runBare(TestCase.java:127)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 08:58:32 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 30 Jun 2009 08:58:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-99) Track component
	updates
Message-ID: <1859063348.1246366712646.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Track component updates
-----------------------

                 Key: JBJCA-99
                 URL: https://jira.jboss.org/jira/browse/JBJCA-99
             Project: JBoss JCA
          Issue Type: Task
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Track component updates for 1.0.0.Alpha2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 16:46:31 2009
From: jira-events at lists.jboss.org (Brian Dill (JIRA))
Date: Tue, 30 Jun 2009 16:46:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-116) Support for SQL
 Server 2.0 driver (JDBC 4.0)
Message-ID: <1361605096.1246394791395.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Support for SQL Server 2.0 driver (JDBC 4.0)
--------------------------------------------

                 Key: HIBERNATE-116
                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-116
             Project: Hibernate
          Issue Type: Feature Request
            Reporter: Brian Dill
            Assignee: Steve Ebersole




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 17:30:31 2009
From: jira-events at lists.jboss.org (Brian Dill (JIRA))
Date: Tue, 30 Jun 2009 17:30:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (HIBERNATE-116) Support for SQL
 Server 2.0 driver (JDBC 4.0)
Message-ID: <1122814292.1246397431380.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/HIBERNATE-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Dill deleted HIBERNATE-116:
---------------------------------


> Support for SQL Server 2.0 driver (JDBC 4.0)
> --------------------------------------------
>
>                 Key: HIBERNATE-116
>                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-116
>             Project: Hibernate
>          Issue Type: Feature Request
>            Reporter: Brian Dill
>            Assignee: Steve Ebersole
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 11:51:08 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 30 Jun 2009 11:51:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2151) Parser exceptions
Message-ID: <1492226254.1246377068806.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Parser exceptions
-----------------

                 Key: JBRULES-2151
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2151
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


Parser errors that raise the  "Contact the development team" message.

=================
a similar "contact-developers-bug" occurs when you write an empty not CE:
   not( )
=================



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 06:17:28 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 30 Jun 2009 06:17:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1005) TCPGOSSIP / TCP
 combination fails to find any members
Message-ID: <1192163503.1246357048948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

TCPGOSSIP / TCP combination fails to find any members
-----------------------------------------------------

                 Key: JGRP-1005
                 URL: https://jira.jboss.org/jira/browse/JGRP-1005
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


The TCPGOSSIP:TCP combination doesn't find an initial membership. The issue is in TCPGOSSIP, where an initial lookup doesn't return the physical addrs associated with logical addrs.

Use Draw with JGroups/conf/tcpgossip.xml to reproduce

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 12:36:08 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 30 Jun 2009 12:36:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-99) Track component
	updates
In-Reply-To: <1859063348.1246366712646.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1768762605.1246379768683.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-99:
---------------------------------

    Component/s: Build


> Track component updates
> -----------------------
>
>                 Key: JBJCA-99
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-99
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Track component updates for 1.0.0.Alpha2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 04:06:28 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 30 Jun 2009 04:06:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7063) Upgrade EJB3 to
	1.1.8
In-Reply-To: <31881366.1246284776868.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1553539392.1246349188882.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-7063.
--------------------------------

    Resolution: Done


Done in r90686.

> Upgrade EJB3 to 1.1.8
> ---------------------
>
>                 Key: JBAS-7063
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7063
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Upgrade to the latest released EJB3 1.1.8 version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 04:06:28 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 30 Jun 2009 04:06:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7061) Upgrade EJB3 to
	1.1.8
In-Reply-To: <15406494.1246284658866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1129509323.1246349188954.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-7061.
--------------------------------

    Resolution: Done


> Upgrade EJB3 to 1.1.8
> ---------------------
>
>                 Key: JBAS-7061
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7061
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Upgrade to the latest released EJB3 1.1.8 version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 13:32:31 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 30 Jun 2009 13:32:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-91) SerialVersionUID test
 detecting mismatch with org.jboss.managed.plugins.ManagedObjectImpl
Message-ID: <2047708221.1246383151330.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SerialVersionUID test detecting mismatch with org.jboss.managed.plugins.ManagedObjectImpl
-----------------------------------------------------------------------------------------

                 Key: JBMAN-91
                 URL: https://jira.jboss.org/jira/browse/JBMAN-91
             Project: JBoss Managed
          Issue Type: Bug
          Components: general
            Reporter: Shelly McGowan
            Assignee: Scott M Stark
             Fix For: JBossMan.2.1.1.GA 


Since 2.1.1.CR1 release, JBoss AS integration testsuite showing this failure when compariing serialVer UIDs to 500 and 501:
FAIL: serialVersionUID error for org.jboss.managed.plugins.ManagedObjectImpl, 500 2, current: 3
FAIL: serialVersionUID error for org.jboss.managed.plugins.ManagedObjectImpl, 501 2, current: 3

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 11:53:08 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 30 Jun 2009 11:53:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2151) Parser exceptions
In-Reply-To: <1492226254.1246377068806.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <55726961.1246377188920.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli updated JBRULES-2151:
-----------------------------------

    Attachment: droolError.GIF


> Parser exceptions
> -----------------
>
>                 Key: JBRULES-2151
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2151
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>         Attachments: droolError.GIF
>
>
> Parser errors that raise the  "Contact the development team" message.
> =================
> a similar "contact-developers-bug" occurs when you write an empty not CE:
>    not( )
> =================

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 17:44:31 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 30 Jun 2009 17:44:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7067) Give some context to
 failed creation of WebResourcePermission
Message-ID: <1698673831.1246398271397.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Give some context to failed creation of WebResourcePermission
-------------------------------------------------------------

                 Key: JBAS-7067
                 URL: https://jira.jboss.org/jira/browse/JBAS-7067
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


The following exception: 

Caused by: java.lang.IllegalArgumentException: illegal HTTP method
	at javax.security.jacc.HttpMethodSpec.makeMethodSet(HttpMethodSpec.java:100)
	at javax.security.jacc.HttpMethodSpec.getMethodSet(HttpMethodSpec.java:74)
	at javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:137)
	at org.jboss.web.WebPermissionMapping.createPermissions(WebPermissionMapping.java:220)

...could give the developer a better indication of what went wrong.  Wrap and provide this context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 20:03:31 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 30 Jun 2009 20:03:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2152)
 KnowledgeAgentConfiguration -
 allow for property "drools.agent.newInstance" to be set to false
Message-ID: <1223905269.1246406611567.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Neale reassigned JBRULES-2152:
--------------------------------------

    Assignee: Mark Proctor  (was: Michael Neale)


Mark - can you confirm that you can set this in a properties file but not the change set - and that is the way it should be? 

> KnowledgeAgentConfiguration - allow for property "drools.agent.newInstance" to be set to false
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2152
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2152
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Tihomir Surdilovic
>            Assignee: Mark Proctor
>
> Currently drools.agent.newInstance is hardcoded to true. we need to be able to set it to false as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 20:03:31 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 30 Jun 2009 20:03:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2152)
 KnowledgeAgentConfiguration
 - allow for property "drools.agent.newInstance" to be set to false
Message-ID: <1823175586.1246406611407.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474372#action_12474372 ] 

Michael Neale commented on JBRULES-2152:
----------------------------------------

This might not be an issue - you can set this in the KA configuration *properties*, which are global to all KAs - but not on a per changeset basis. 

> KnowledgeAgentConfiguration - allow for property "drools.agent.newInstance" to be set to false
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2152
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2152
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Tihomir Surdilovic
>            Assignee: Michael Neale
>
> Currently drools.agent.newInstance is hardcoded to true. we need to be able to set it to false as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 19:48:31 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 30 Jun 2009 19:48:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBRULES-2152)
 KnowledgeAgentConfiguration -
 allow for property "drools.agent.newInstance" to be set to false
Message-ID: <2005828456.1246405711311.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Neale moved GUVNOR-376 to JBRULES-2152:
-----------------------------------------------

              Project: JBoss Drools  (was: Guvnor)
                  Key: JBRULES-2152  (was: GUVNOR-376)
    Affects Version/s: 5.0.1.FINAL
                           (was: drools-5.0.1.FINAL)


> KnowledgeAgentConfiguration - allow for property "drools.agent.newInstance" to be set to false
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2152
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2152
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Tihomir Surdilovic
>            Assignee: Michael Neale
>
> Currently drools.agent.newInstance is hardcoded to true. we need to be able to set it to false as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 06:26:28 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 30 Jun 2009 06:26:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1005) TCPGOSSIP / TCP
 combination fails to find any members
In-Reply-To: <1192163503.1246357048948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <590839785.1246357588960.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474266#action_12474266 ] 

Bela Ban commented on JGRP-1005:
--------------------------------

That's because the GossipRouter doesn't maintain bindings between logical and physical addrs. Actually, it is probably sufficient to simply return a list of *physical* addresses, similar to TCPPING.

> TCPGOSSIP / TCP combination fails to find any members
> -----------------------------------------------------
>
>                 Key: JGRP-1005
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1005
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> The TCPGOSSIP:TCP combination doesn't find an initial membership. The issue is in TCPGOSSIP, where an initial lookup doesn't return the physical addrs associated with logical addrs.
> Use Draw with JGroups/conf/tcpgossip.xml to reproduce

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 13:49:31 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 30 Jun 2009 13:49:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-6773)
 org.jboss.test.jmx.test.UndeployBrokenPackageUnitTestCase
In-Reply-To: <11736314.1239664702380.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1339481216.1246384171285.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reopened JBAS-6773:
----------------------------------



This issue is now seen in trunk testsuite.  Reopening to track.

> org.jboss.test.jmx.test.UndeployBrokenPackageUnitTestCase
> ---------------------------------------------------------
>
>                 Key: JBAS-6773
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6773
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: hs_err_pid16939.log
>
>
> JBoss-AS-5.1.x-TestSuite-sun15-sun16 and JBoss-AS-5.1.x-TestSuite-sun16-sun16 are not completing due to a Sun JVM crash which occurs during the execution of this test case.  The same issue was seen in 5.0.0.GA.  See linked issue for the discussion and resolution.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 13:49:31 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 30 Jun 2009 13:49:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6773)
 org.jboss.test.jmx.test.UndeployBrokenPackageUnitTestCase
In-Reply-To: <11736314.1239664702380.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <828727184.1246384171381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6773:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
                       (was: JBossAS-5.1.0.GA)


> org.jboss.test.jmx.test.UndeployBrokenPackageUnitTestCase
> ---------------------------------------------------------
>
>                 Key: JBAS-6773
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6773
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: hs_err_pid16939.log
>
>
> JBoss-AS-5.1.x-TestSuite-sun15-sun16 and JBoss-AS-5.1.x-TestSuite-sun16-sun16 are not completing due to a Sun JVM crash which occurs during the execution of this test case.  The same issue was seen in 5.0.0.GA.  See linked issue for the discussion and resolution.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 06:33:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 30 Jun 2009 06:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1666) Add
 "messageCount" attribute on Address MBean
In-Reply-To: <18851986.1245825537257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1209930346.1246358009136.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1666:
---------------------------------

    Fix Version/s: 2.0.0


> Add "messageCount" attribute on Address MBean
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1666
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1666
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Value shown in "messageCount" attribute of a queue MBean does not include the number of messages that are paged. This is because messages are paged to disk  before they are routed in the postoffice. So, for the user to be able to find the total number of messages that are added to a queue, Tim suggested that, we add a "messageCount" attribute to the Address MBean. That would indicate how many messages are paged for a particular destination address.  Please refer http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157325 for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 11:58:08 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 30 Jun 2009 11:58:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-202) BeansDeployer
 cannot be recycled
Message-ID: <1676631077.1246377488627.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

BeansDeployer cannot be recycled
--------------------------------

                 Key: JBDEPLOY-202
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-202
             Project: JBoss Deployers
          Issue Type: Bug
          Components: classloading
    Affects Versions: JBDEPLOY-2.0.5.GA
            Reporter: Thomas Diesler
            Assignee: Thomas Diesler
             Fix For:  JBDEPLOY-2.2.x


Caused by: java.lang.ClassCastException
at java.lang.Class.cast(Class.java:2990)
at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:215)
at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132)
at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118)
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:239)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:330)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 17:58:31 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 30 Jun 2009 17:58:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7067) Give some context
 to failed creation of WebResourcePermission
In-Reply-To: <1698673831.1246398271397.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <187352341.1246399111373.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-7067.
---------------------------------------

    Resolution: Done


> Give some context to failed creation of WebResourcePermission
> -------------------------------------------------------------
>
>                 Key: JBAS-7067
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7067
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The following exception: 
> Caused by: java.lang.IllegalArgumentException: illegal HTTP method
> 	at javax.security.jacc.HttpMethodSpec.makeMethodSet(HttpMethodSpec.java:100)
> 	at javax.security.jacc.HttpMethodSpec.getMethodSet(HttpMethodSpec.java:74)
> 	at javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:137)
> 	at org.jboss.web.WebPermissionMapping.createPermissions(WebPermissionMapping.java:220)
> ...could give the developer a better indication of what went wrong.  Wrap and provide this context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 17:46:31 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 30 Jun 2009 17:46:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7067) Give some context
 to failed creation of WebResourcePermission
In-Reply-To: <1698673831.1246398271397.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1704944178.1246398391281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474366#action_12474366 ] 

Andrew Lee Rubinger commented on JBAS-7067:
-------------------------------------------

Now wrapped in:

Caused by: java.lang.IllegalArgumentException: Could not create resource permission with pattern "/restricted/*" and methods: !GET,POST
   at org.jboss.web.WebPermissionMapping.createPermissions(WebPermissionMapping.java:229)

> Give some context to failed creation of WebResourcePermission
> -------------------------------------------------------------
>
>                 Key: JBAS-7067
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7067
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The following exception: 
> Caused by: java.lang.IllegalArgumentException: illegal HTTP method
> 	at javax.security.jacc.HttpMethodSpec.makeMethodSet(HttpMethodSpec.java:100)
> 	at javax.security.jacc.HttpMethodSpec.getMethodSet(HttpMethodSpec.java:74)
> 	at javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:137)
> 	at org.jboss.web.WebPermissionMapping.createPermissions(WebPermissionMapping.java:220)
> ...could give the developer a better indication of what went wrong.  Wrap and provide this context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 13:28:31 2009
From: jira-events at lists.jboss.org (Art Plata (JIRA))
Date: Tue, 30 Jun 2009 13:28:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <1760479310.1246382911558.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474351#action_12474351 ] 

Art Plata commented on JBMESSAGING-1661:
----------------------------------------

I got this working by copying the source for Bridge.java in 1.4.4, to 1.4.3. The Remote cluster receives messages fine, but now we're running into an issue with messages getting stuck when we try to test fail-over on the remote cluster. This looks like a separate issue. Should i open a new bug? 

> 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://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.5.GA
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 16:08:31 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 30 Jun 2009 16:08:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-202) BeansDeployer
 cannot be recycled
In-Reply-To: <1676631077.1246377488627.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1611067409.1246392511324.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474364#action_12474364 ] 

Thomas Diesler commented on JBDEPLOY-202:
-----------------------------------------

Fixed in 2.0.5.SP1

Still affects 2.0.6.GA, 2.0.7.GA, 2.0.8.GA

Changes are not ported to Branch_2_0 because this branch uses JBossXBHelper from jbossxb-2.0.1.GA. 
The issue with the JBossXBHelper needs to be fixed there - to be discussed.

Also not ported to trunk for the same reason.

> BeansDeployer cannot be recycled
> --------------------------------
>
>                 Key: JBDEPLOY-202
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-202
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: classloading
>    Affects Versions: JBDEPLOY-2.0.5.GA
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For:  JBDEPLOY-2.2.x
>
>
> Caused by: java.lang.ClassCastException
> at java.lang.Class.cast(Class.java:2990)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:215)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:239)
> at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:330)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 11:05:08 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Tue, 30 Jun 2009 11:05:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2150) stream mode
 requires DroolsStreamUtils
Message-ID: <114326829.1246374308757.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

stream mode requires DroolsStreamUtils
--------------------------------------

                 Key: JBRULES-2150
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2150
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core (fusion)
    Affects Versions: 5.0.1.FINAL
            Reporter: Jaroslaw Kijanowski
            Assignee: Edson Tirelli
         Attachments: cep.drl, CEPTest.java, Sensor.java

I'm using sliding windows (hence stream mode).
Here's my rule:

rule 'r'
when
Number( dv:doubleValue > 1 ) from accumulate(
        Sensor( $v : value ) over window:length( 2 ),
        average( $v ) )
then
    System.out.println(dv);
end

Here's my class:

++++++++++++++++++++++++++++++++++++++++++++++
public class CEPTest {
  public static void main(String[] args) throws Exception {
.
.
.
    kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
    KnowledgeBase kbase2 = (KnowledgeBase) DroolsStreamUtils.streamIn(DroolsStreamUtils.streamOut(kbase), null);

    final StatefulKnowledgeSession ksession = kbase2.newStatefulKnowledgeSession();

    System.out.println("T1");
    ksession.insert(new Sensor(1.0));
    ksession.fireAllRules();

    System.out.println("T2");
    ksession.insert(new Sensor(2.0));
    ksession.fireAllRules();

    System.out.println("T3");
    ksession.insert(new Sensor(3.0));
    ksession.fireAllRules();

    ksession.dispose();
  }
}
++++++++++++++++++++++++++++++++++++++++++++++
The output is (as expected):
+++++++++++++++
T1
T2
1.5
T3
2.5
+++++++++++++++

I'm wondering why I have to use DroolsStreamUtils to get a knowledge base? When I use kbase (which didn't went through DroolsStreamUtils) instead of kbase2 to create a new session, the output will be:
+++++++++++++++
T1
T2
2.0
T3
3.0
+++++++++++++++ 

Attaching all 3 files needed to reproduce - rule, model and test.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 14:10:31 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 30 Jun 2009 14:10:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1804) Logical
 insertion lingers
 after the rule that inserted it no longer supports it (with testcase patch)
In-Reply-To: <7576319.1224262460882.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1857414143.1246385431739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474354#action_12474354 ] 

Geoffrey De Smet commented on JBRULES-1804:
-------------------------------------------

Laurent on the mailing list ran into this one too.

It happens when you calculate the weight of a constraintoccurrence based on property of a fact and that property isn't stable (although the working memory has been notified that the fact was changes, so it property could have changed)

> Logical insertion lingers after the rule that inserted it no longer supports it (with testcase patch)
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1804
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1804
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions:  5.0.0.M2
>            Reporter: Geoffrey De Smet
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.1.0.M1
>
>
> This one got me headscratching for a while, untill I realized what the problem is.
> Tim reported on the mailing list he ran into it to.
> I've commmited a testcase in subversion, in TruthMaintenanceTest, called
>    disabled_testLogicalInsertionsModifySameRuleGivesDifferentLogicalInsertion
> Remove the "disabled_" to enable it and try it out.
> Here's what happens in the testcase:
> 3 sensors with tempature 100, 200 and 200 are inserted.
> There's a rule which logically inserts all encountered tempatures, so 100 and 200.
> Then the first sensor modifies to a tempature of 150.
> As it turns out, the encoutered tempatures should be 150 and 200 now, but instead it's 100, 150 and 200.
> Even though there is no sensor that has a tempature of 100.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 11:58:08 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 30 Jun 2009 11:58:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-202) BeansDeployer
 cannot be recycled
In-Reply-To: <1676631077.1246377488627.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <64104868.1246377488778.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474330#action_12474330 ] 

Thomas Diesler commented on JBDEPLOY-202:
-----------------------------------------

The underlying issue is that BeansDeployer uses an JBossXBDeployerHelper

BeansDeployer -> SchemaResolverDeployer -> JBossXBDeployer

The JBossXBDeployerHelper uses

   private static DefaultSchemaResolver resolver = (DefaultSchemaResolver)SingletonSchemaResolverFactory.getInstance().getSchemaBindingResolver();

which internally caches the classes.

>From what I can see SingletonSchemaResolverFactory is evil and cannot be used in an OSGi environment.


> BeansDeployer cannot be recycled
> --------------------------------
>
>                 Key: JBDEPLOY-202
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-202
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: classloading
>    Affects Versions: JBDEPLOY-2.0.5.GA
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For:  JBDEPLOY-2.2.x
>
>
> Caused by: java.lang.ClassCastException
> at java.lang.Class.cast(Class.java:2990)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:215)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:239)
> at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:330)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 15:12:31 2009
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Tue, 30 Jun 2009 15:12:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-549) ConnectionTable:
 spurious Connection instances on concurrent connects
In-Reply-To: <10580511.1183710592881.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1033076656.1246389151306.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474359#action_12474359 ] 

Dennis Reed commented on JGRP-549:
----------------------------------

Backported another change to the 2.4.x branch to short-circuit local messages, to fix a regression issue.

> ConnectionTable: spurious Connection instances on concurrent connects
> ---------------------------------------------------------------------
>
>                 Key: JGRP-549
>                 URL: https://jira.jboss.org/jira/browse/JGRP-549
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6
>
>
> If we have members A and B, and they don't yet have connections to each other, and start sending messages to each other at the exact same time, then we run into the following scenario:
> - A attempts to connect to B (new Socket())
> - B attempts to connect to A
> - A accepts B's connection and adds an entry for B into its table
> - B adds an entry for A into its table
> - B gets the accept() from A, but doesn't add the new Connection into its table because there is already a Connection. This leads to a spurious Connection object, which will only be closed and garbage collected once A or B leaves the cluster
> - We used to close Connections which were already in the table, but this lead to ping-pong effects where concurrent initial senders always closed each others connections
> - Even worse: a new Socket() always creates a new Connection object and places it into the table, *regardless* of whether a Connection for a given destination already exists or not !
> GOAL:
> #1 Have only 1 TCP connection between any 2 members
> #2 Establish a handshaking mechanism, to avoid spurious connections
> SOLUTION:
> - When A establishes a connection to B, A needs to get agreement from B first (and vice versa)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 11:05:08 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Tue, 30 Jun 2009 11:05:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2150) stream mode
 requires DroolsStreamUtils
In-Reply-To: <114326829.1246374308757.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <793890624.1246374308917.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jaroslaw Kijanowski updated JBRULES-2150:
-----------------------------------------

    Attachment: Sensor.java
                CEPTest.java
                cep.drl


> stream mode requires DroolsStreamUtils
> --------------------------------------
>
>                 Key: JBRULES-2150
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2150
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Jaroslaw Kijanowski
>            Assignee: Edson Tirelli
>         Attachments: cep.drl, CEPTest.java, Sensor.java
>
>
> I'm using sliding windows (hence stream mode).
> Here's my rule:
> rule 'r'
> when
> Number( dv:doubleValue > 1 ) from accumulate(
>         Sensor( $v : value ) over window:length( 2 ),
>         average( $v ) )
> then
>     System.out.println(dv);
> end
> Here's my class:
> ++++++++++++++++++++++++++++++++++++++++++++++
> public class CEPTest {
>   public static void main(String[] args) throws Exception {
> .
> .
> .
>     kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
>     KnowledgeBase kbase2 = (KnowledgeBase) DroolsStreamUtils.streamIn(DroolsStreamUtils.streamOut(kbase), null);
>     final StatefulKnowledgeSession ksession = kbase2.newStatefulKnowledgeSession();
>     System.out.println("T1");
>     ksession.insert(new Sensor(1.0));
>     ksession.fireAllRules();
>     System.out.println("T2");
>     ksession.insert(new Sensor(2.0));
>     ksession.fireAllRules();
>     System.out.println("T3");
>     ksession.insert(new Sensor(3.0));
>     ksession.fireAllRules();
>     ksession.dispose();
>   }
> }
> ++++++++++++++++++++++++++++++++++++++++++++++
> The output is (as expected):
> +++++++++++++++
> T1
> T2
> 1.5
> T3
> 2.5
> +++++++++++++++
> I'm wondering why I have to use DroolsStreamUtils to get a knowledge base? When I use kbase (which didn't went through DroolsStreamUtils) instead of kbase2 to create a new session, the output will be:
> +++++++++++++++
> T1
> T2
> 2.0
> T3
> 3.0
> +++++++++++++++ 
> Attaching all 3 files needed to reproduce - rule, model and test.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 11:07:09 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Tue, 30 Jun 2009 11:07:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-446)
 bean-deployer xsds don't contain web references
In-Reply-To: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <252015958.1246374429102.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMICROCONT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474318#action_12474318 ] 

Wolfgang Knauf commented on JBMICROCONT-446:
--------------------------------------------

The "rcase-RecurseLax.2" error is also discussed here:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=145209
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223327

> bean-deployer xsds don't contain web references
> -----------------------------------------------
>
>                 Key: JBMICROCONT-446
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Wolfgang Knauf
>            Assignee: Kabir Khan
>
> bean-deployer_2_0.xsd:
>    <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
> =>should point. 
>    <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">
> The comment for a sample instance should also contain a schema location attribute:
>          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xmlns="urn:jboss:bean-deployer:2.0"
>             xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">
> ==================
> bean-deployer_1_0.xsd:
> The comment for a sample instance should point to the web schema location:
>          <deployment
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
>             xmlns="urn:jboss:bean-deployer">
> =================
> policy_1_0.xsd:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
> should be:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>
> =================
> bean-deployer_2_0.xsd raises validation errors in Eclipse:
> -rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
> -src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
> According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 01:04:57 2009
From: jira-events at lists.jboss.org (Jeff Wexler (JIRA))
Date: Mon, 1 Jun 2009 01:04:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6333)
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <27205402.1229614674680.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4756351.1243832697063.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470048#action_12470048 ] 

Jeff Wexler commented on JBAS-6333:
-----------------------------------

I am using 5.0.1.

The change to
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 

instead of 
<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends>

is still not in docs/examples/jms/postgresql-persistence-service.xml

I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors.

It appears from the comments of this jira issue that plans were to make this change to the persistence-service.xml scripts. If so, it would appear that this is still open.

> <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------
>
>                 Key: JBAS-6333
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6333
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.0.0.GA
>            Reporter: Clebert Suconic
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: JBossAS-5.1.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 01:07:15 2009
From: jira-events at lists.jboss.org (Jeff Wexler (JIRA))
Date: Mon, 1 Jun 2009 01:07:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6333)
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <27205402.1229614674680.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32125887.1243832835446.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470049#action_12470049 ] 

Jeff Wexler commented on JBAS-6333:
-----------------------------------

Sorry typo in my comment above.
The version that I am using is 5.1.0.GA   (Not 5.0.1)

> <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------
>
>                 Key: JBAS-6333
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6333
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.0.0.GA
>            Reporter: Clebert Suconic
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: JBossAS-5.1.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 01:11:56 2009
From: jira-events at lists.jboss.org (Jeff Wexler (JIRA))
Date: Mon, 1 Jun 2009 01:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6991) Still issue in
 5.1.0.GA
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
Message-ID: <25176794.1243833116559.JavaMail.jira@cloud.prod.atl2.jboss.com>

Still issue in 5.1.0.GA <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
--------------------------------------------------------------------------------------------------------------

                 Key: JBAS-6991
                 URL: https://jira.jboss.org/jira/browse/JBAS-6991
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS (JBoss Messaging)
    Affects Versions: JBossAS-5.0.0.GA
            Reporter: Jeff Wexler
            Assignee: Howard Gao
            Priority: Minor
             Fix For: JBossAS-5.1.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 01:25:56 2009
From: jira-events at lists.jboss.org (Jeff Wexler (JIRA))
Date: Mon, 1 Jun 2009 01:25:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6991) Still issue in
 5.1.0.GA
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <25176794.1243833116559.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7225966.1243833956605.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Wexler updated JBAS-6991:
------------------------------

    Workaround Description: https://jira.jboss.org/jira/browse/JBAS-6333  (was: Change the depends attribute to a simple attribute:

it should be
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute>

instead of 

<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends>)
               Environment: Windows 2003 Server
         Affects Version/s: JBossAS-5.1.0.GA
                                (was: JBossAS-5.0.0.GA)
               Description: 
https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS-6333 was closed.

I recognize that I may have misunderstood the intentions of the developers on JBAS-6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.

I did not see how to re-open JBAS-6333 and thus am creating a new issue in jira.

The change to 
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 

instead of 
<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 

is still not in docs/examples/jms/postgresql-persistence-service.xml 

I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 



> Still issue in 5.1.0.GA <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6991
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6991
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows 2003 Server
>            Reporter: Jeff Wexler
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: JBossAS-5.1.0.Beta1
>
>
> https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS-6333 was closed.
> I recognize that I may have misunderstood the intentions of the developers on JBAS-6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.
> I did not see how to re-open JBAS-6333 and thus am creating a new issue in jira.
> The change to 
> <attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 
> instead of 
> <depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 
> is still not in docs/examples/jms/postgresql-persistence-service.xml 
> I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 01:27:56 2009
From: jira-events at lists.jboss.org (Jeff Wexler (JIRA))
Date: Mon, 1 Jun 2009 01:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6991) Still issue in
 5.1.0.GA
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <25176794.1243833116559.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13261367.1243834076669.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Wexler updated JBAS-6991:
------------------------------

    Fix Version/s:     (was: JBossAS-5.1.0.Beta1)


> Still issue in 5.1.0.GA <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6991
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6991
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows 2003 Server
>            Reporter: Jeff Wexler
>            Assignee: Howard Gao
>            Priority: Minor
>
> https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS-6333 was closed.
> I recognize that I may have misunderstood the intentions of the developers on JBAS-6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.
> I did not see how to re-open JBAS-6333 and thus am creating a new issue in jira.
> The change to 
> <attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 
> instead of 
> <depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 
> is still not in docs/examples/jms/postgresql-persistence-service.xml 
> I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 01:27:56 2009
From: jira-events at lists.jboss.org (Jeff Wexler (JIRA))
Date: Mon, 1 Jun 2009 01:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6991) Still issue in
 5.1.0.GA
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <25176794.1243833116559.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30082493.1243834076825.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Wexler updated JBAS-6991:
------------------------------

    Description: 
https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS - 6333 was closed.

I recognize that I may have misunderstood the intentions of the developers on JBAS - 6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.

I did not see how to re-open JBAS - 6333 and thus am creating a new issue in jira.

The change to 
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 

instead of 
<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 

is still not in docs/examples/jms/postgresql-persistence-service.xml 

I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 


  was:
https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS-6333 was closed.

I recognize that I may have misunderstood the intentions of the developers on JBAS-6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.

I did not see how to re-open JBAS-6333 and thus am creating a new issue in jira.

The change to 
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 

instead of 
<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 

is still not in docs/examples/jms/postgresql-persistence-service.xml 

I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 




> Still issue in 5.1.0.GA <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6991
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6991
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows 2003 Server
>            Reporter: Jeff Wexler
>            Assignee: Howard Gao
>            Priority: Minor
>
> https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS - 6333 was closed.
> I recognize that I may have misunderstood the intentions of the developers on JBAS - 6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.
> I did not see how to re-open JBAS - 6333 and thus am creating a new issue in jira.
> The change to 
> <attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 
> instead of 
> <depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 
> is still not in docs/examples/jms/postgresql-persistence-service.xml 
> I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 02:33:56 2009
From: jira-events at lists.jboss.org (Jeff Wexler (JIRA))
Date: Mon, 1 Jun 2009 02:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6991) Still issue in
 5.1.0.GA
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <25176794.1243833116559.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9022439.1243838036577.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Wexler updated JBAS-6991:
------------------------------

    Description: 
https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS - 6333 was closed.

I recognize that I may have misunderstood the intentions of the developers on JBAS - 6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.

I did not see how to re-open JBAS - 6333 and thus am creating a new issue in jira.

The change to 
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 

instead of 
<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 

is still not in docs/examples/jms/postgresql-persistence-service.xml 

I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 

However, other encountered other messaging errors when running the booking example using postgresql and thus commented out the attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory statement.

Perhaps, this statement should be commented out in the original <database>-persistence-service.xml files?

  was:
https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS - 6333 was closed.

I recognize that I may have misunderstood the intentions of the developers on JBAS - 6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.

I did not see how to re-open JBAS - 6333 and thus am creating a new issue in jira.

The change to 
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 

instead of 
<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 

is still not in docs/examples/jms/postgresql-persistence-service.xml 

I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 




> Still issue in 5.1.0.GA <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6991
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6991
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows 2003 Server
>            Reporter: Jeff Wexler
>            Assignee: Howard Gao
>            Priority: Minor
>
> https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS - 6333 was closed.
> I recognize that I may have misunderstood the intentions of the developers on JBAS - 6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.
> I did not see how to re-open JBAS - 6333 and thus am creating a new issue in jira.
> The change to 
> <attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 
> instead of 
> <depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 
> is still not in docs/examples/jms/postgresql-persistence-service.xml 
> I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 
> However, other encountered other messaging errors when running the booking example using postgresql and thus commented out the attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory statement.
> Perhaps, this statement should be commented out in the original <database>-persistence-service.xml files?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 02:55:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 1 Jun 2009 02:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6991) Still issue in
 5.1.0.GA
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <25176794.1243833116559.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6309096.1243839356475.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470054#action_12470054 ] 

Howard Gao commented on JBAS-6991:
----------------------------------

Hi Jeff,

Are you saying that even you have made the change, you still have other errors? If so, what are they?

Thanks,
Howard


> Still issue in 5.1.0.GA <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6991
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6991
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows 2003 Server
>            Reporter: Jeff Wexler
>            Assignee: Howard Gao
>            Priority: Minor
>
> https://jira.jboss.org/jira/browse/JBAS-6333 appears to still be open in 5.1.0.GA even though it was reported as fixed in JBossAS-5.1.0.Beta1 and JBAS - 6333 was closed.
> I recognize that I may have misunderstood the intentions of the developers on JBAS - 6333 for each user to find the instructions on the workaround here and make the changes themselves rather than for the workaround to be incorporated in the scripts in docs/examples/jms? If that was the intention, I would propose that it would be better to make the change in the scripts rather than requiring the users to find the work around and make the change themselves.
> I did not see how to re-open JBAS - 6333 and thus am creating a new issue in jira.
> The change to 
> <attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> 
> instead of 
> <depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> 
> is still not in docs/examples/jms/postgresql-persistence-service.xml 
> I just manually made the change to avert the Dependency "jboss.messaging:service=PostOffice" (should be in state "Create", but is actually in state "Configured") errors. 
> However, other encountered other messaging errors when running the booking example using postgresql and thus commented out the attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory statement.
> Perhaps, this statement should be commented out in the original <database>-persistence-service.xml files?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 03:02:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 1 Jun 2009 03:02:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (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: <25230422.1243839777112.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1631:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>         Attachments: logs-and-config-prod.zip, logs-and-config-test.zip
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 03:04:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 1 Jun 2009 03:04:56 -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: <6515510.1243839896659.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1631:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: logs-and-config-prod.zip, logs-and-config-test.zip
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 03:21:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 1 Jun 2009 03:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6333)
 <database>-persistence-service.xml is dependent on ChannelFactory even on
 NonClustered
In-Reply-To: <27205402.1229614674680.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31317725.1243840916610.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470057#action_12470057 ] 

Howard Gao commented on JBAS-6333:
----------------------------------

The changes has not been made to AS 5 repository.

As Jeff already created another issue for that. I will not re-open it. 

> <database>-persistence-service.xml is dependent on ChannelFactory even on NonClustered
> --------------------------------------------------------------------------------------
>
>                 Key: JBAS-6333
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6333
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.0.0.GA
>            Reporter: Clebert Suconic
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: JBossAS-5.1.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 04:28:56 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Mon, 1 Jun 2009 04:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Admin Join problem
 -GMS flush by coordinator failed
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4748314.1243844936585.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470060#action_12470060 ] 

Vladimir Blagojevic commented on JGRP-985:
------------------------------------------

I've looked through this example and I am not sure about the following. First, why did you comment out UNICAST protocol? In tests like this one use a default udp.xml stack provided in distribution. Second, why are you getting state if there is no state in application, you do not implement state installation callbacks? 



> Admin  Join problem -GMS flush by coordinator failed
> ----------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 05:02:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 1 Jun 2009 05:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <1097617.1243846976786.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470061#action_12470061 ] 

Howard Gao commented on JBMESSAGING-1631:
-----------------------------------------

Hi Victor,

Do you have a test MDB for the issue? I'm trying to make a test to reproduce it. Thanks.

Howard


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: logs-and-config-prod.zip, logs-and-config-test.zip
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 06:24:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 1 Jun 2009 06:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1840) StrictMaxPool
 does not
 maintain a correct "inUse" count leading to incorrect reporting of
 "AvailableCount"
Message-ID: <742346.1243851896474.JavaMail.jira@cloud.prod.atl2.jboss.com>

StrictMaxPool does not maintain a correct "inUse" count leading to incorrect reporting of "AvailableCount"
----------------------------------------------------------------------------------------------------------

                 Key: EJBTHREE-1840
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1840
             Project: EJB 3.0
          Issue Type: Bug
          Components: pool
    Affects Versions: 1.1.6
            Reporter: jaikiran pai
            Assignee: jaikiran pai
             Fix For: 1.1.7


The org.jboss.ejb3.test.stateless.unit.MetricsUnitTestCase shows a failure w.r.t the "AvailableCount" of a bean marked with StrictMaxPool. 

The StrictMaxPool internally implements the getAvailableCount() as follows:

   public int getAvailableCount()
   {
      return maxSize - inUse;
   }


The "inUse" count is handled incorrectly in the discard and remove method of this pool leading to that count reaching a negative value. Ultimately, this leads to incorrect available count being reported.

When an exception occurs, the bean is discarded from the pool. This leads to a call on discard method of the StrictMaxPool which decrements the inUse count and then calls the remove method which *again* decrements the inUse count for the same bean context.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 06:31:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 1 Jun 2009 06:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1840) StrictMaxPool
 does not
 maintain a correct "inUse" count leading to incorrect reporting of
 "AvailableCount"
In-Reply-To: <742346.1243851896474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29602325.1243852316434.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1840:
-----------------------------------

    Component/s: core
                     (was: pool)


> StrictMaxPool does not maintain a correct "inUse" count leading to incorrect reporting of "AvailableCount"
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1840
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1840
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.6
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> The org.jboss.ejb3.test.stateless.unit.MetricsUnitTestCase shows a failure w.r.t the "AvailableCount" of a bean marked with StrictMaxPool. 
> The StrictMaxPool internally implements the getAvailableCount() as follows:
>    public int getAvailableCount()
>    {
>       return maxSize - inUse;
>    }
> The "inUse" count is handled incorrectly in the discard and remove method of this pool leading to that count reaching a negative value. Ultimately, this leads to incorrect available count being reported.
> When an exception occurs, the bean is discarded from the pool. This leads to a call on discard method of the StrictMaxPool which decrements the inUse count and then calls the remove method which *again* decrements the inUse count for the same bean context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 07:56:56 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 1 Jun 2009 07:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6992) Missing new line in
 MANIFEST.MF cause deployment to fail
Message-ID: <20895033.1243857416511.JavaMail.jira@cloud.prod.atl2.jboss.com>

Missing new line in MANIFEST.MF cause deployment to fail
--------------------------------------------------------

                 Key: JBAS-6992
                 URL: https://jira.jboss.org/jira/browse/JBAS-6992
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployers
    Affects Versions: JBossAS-5.1.0.GA
         Environment: WinXP, jdk 1.6.0u13
            Reporter: Ondrej Medek
            Assignee: Ales Justin


Hi,
I have an exploded EAR, it contains one JAR with session beans. This JAR has the MANIFEST.MF, with Class-Path entry referencing two more JARs (plain JARs, not beans). Whe this Class-Path entry not finished by a new line character, then deployment fails du to the java.lang.ClassNotFoundException. When I have added the new line anfter the Class-Path entry, then everything goes fine.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 08:00:56 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 1 Jun 2009 08:00:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6992) Missing new line in
 MANIFEST.MF cause deployment to fail
In-Reply-To: <20895033.1243857416511.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27614628.1243857656993.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Medek updated JBAS-6992:
-------------------------------

    Attachment: doNothing.ear


Just deploy this file. (Stolen from https://jira.jboss.org/jira/browse/JBAS-6518 and then modified.)

> Missing new line in MANIFEST.MF cause deployment to fail
> --------------------------------------------------------
>
>                 Key: JBAS-6992
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6992
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: WinXP, jdk 1.6.0u13
>            Reporter: Ondrej Medek
>            Assignee: Ales Justin
>         Attachments: doNothing.ear
>
>
> Hi,
> I have an exploded EAR, it contains one JAR with session beans. This JAR has the MANIFEST.MF, with Class-Path entry referencing two more JARs (plain JARs, not beans). Whe this Class-Path entry not finished by a new line character, then deployment fails du to the java.lang.ClassNotFoundException. When I have added the new line anfter the Class-Path entry, then everything goes fine.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 09:16:56 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 1 Jun 2009 09:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6993)
 jboss-main-client.jar is empty in JBoss 5.1.0GA
Message-ID: <20312495.1243862216771.JavaMail.jira@cloud.prod.atl2.jboss.com>

jboss-main-client.jar is empty in JBoss 5.1.0GA
-----------------------------------------------

                 Key: JBAS-6993
                 URL: https://jira.jboss.org/jira/browse/JBAS-6993
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ondrej Medek
            Priority: Optional


May it be removed?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 09:18:56 2009
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 1 Jun 2009 09:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6993)
 jboss-main-client.jar is empty in JBoss 5.1.0GA
In-Reply-To: <20312495.1243862216771.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32381338.1243862336626.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dimitris Andreadis reassigned JBAS-6993:
----------------------------------------

    Assignee: Paul Gier


> jboss-main-client.jar is empty in JBoss 5.1.0GA
> -----------------------------------------------
>
>                 Key: JBAS-6993
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6993
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ondrej Medek
>            Assignee: Paul Gier
>            Priority: Optional
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> May it be removed?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 09:18:56 2009
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 1 Jun 2009 09:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6993)
 jboss-main-client.jar is empty in JBoss 5.1.0GA
In-Reply-To: <20312495.1243862216771.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5913374.1243862336824.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dimitris Andreadis updated JBAS-6993:
-------------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> jboss-main-client.jar is empty in JBoss 5.1.0GA
> -----------------------------------------------
>
>                 Key: JBAS-6993
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6993
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ondrej Medek
>            Assignee: Paul Gier
>            Priority: Optional
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> May it be removed?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 09:32:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 1 Jun 2009 09:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBJCA-29) Testing of JCA xml
	parsing
In-Reply-To: <1681691.1215677367200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4482075.1243863176952.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang closed JBJCA-29.
---------------------------

    Fix Version/s: 1.0.0.Alpha1
       Resolution: Done


see JIRA in Metadata project
https://jira.jboss.org/jira/browse/JBMETA-111
https://jira.jboss.org/jira/browse/JBMETA-158

> Testing of JCA xml parsing
> --------------------------
>
>                 Key: JBJCA-29
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-29
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Adrian Brock
>            Assignee: Jeff Zhang
>            Priority: Minor
>             Fix For: 1.0.0.Alpha1
>
>
> As JBAS-5715 shows (and some earlier problems with the new -ds.xml parsing), 
> the testing of the JCA xml parsing is woefully incomplete in terms of catching regressions.
> There should be systematic tests for each element of ra.xml, jboss-ra.xml, -ds.xml
> * To catch future bugs introduced in the parsing
> * To make sure invalid values are being correctly rejected
> * The xml values are making it through to the artifacts (currently mbeans) in the backend

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 09:34:57 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 1 Jun 2009 09:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBJCA-47) remove compile
 warning and checkstyle error
In-Reply-To: <2619941.1236819880117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13768064.1243863297015.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBJCA-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470085#action_12470085 ] 

Jeff Zhang commented on JBJCA-47:
---------------------------------

we have only two checkstyle warning by JCA API code

[checkstyle] api/src/main/java/javax/resource/spi/Activation.java:64: Unused Javadoc tag.
[checkstyle] api/src/main/java/javax/resource/spi/ConnectionDefinitions.java:51: Unused Javadoc tag.


> remove compile warning and checkstyle error
> -------------------------------------------
>
>                 Key: JBJCA-47
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-47
>             Project: JBoss JCA
>          Issue Type: Sub-task
>          Components: Build
>    Affects Versions: 1.0.0.Alpha1
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha1
>
>
> We use this JIRA to track compile waring removing and fix checkstyle error message

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 09:36:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 1 Jun 2009 09:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-47) remove compile
 warning and checkstyle error
In-Reply-To: <2619941.1236819880117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33507136.1243863416884.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBJCA-47.
-----------------------------

    Resolution: Done


> remove compile warning and checkstyle error
> -------------------------------------------
>
>                 Key: JBJCA-47
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-47
>             Project: JBoss JCA
>          Issue Type: Sub-task
>          Components: Build
>    Affects Versions: 1.0.0.Alpha1
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha1
>
>
> We use this JIRA to track compile waring removing and fix checkstyle error message

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 10:29:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 1 Jun 2009 10:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2392) Selenium tests
	for XSS
In-Reply-To: <23069268.1242226847011.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31998028.1243866596504.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470091#action_12470091 ] 

Viliam Rockai commented on JBPORTAL-2392:
-----------------------------------------

since the selenium has troubles with testing the appearance of unexpected alert i will implement these test in a different way. i'll add  inputa validation test methods to my existing tests. Submitting an XSS string should lead into error message about invalid input.

> Selenium tests for XSS
> ----------------------
>
>                 Key: JBPORTAL-2392
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2392
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal QA
>            Reporter: Viliam Rockai
>            Assignee: Viliam Rockai
>
> Testing XSS on inputs in portal GUI had to be implemented.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 10:37:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 1 Jun 2009 10:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2309) end to end
 admin test for adding new portal
In-Reply-To: <20849835.1234456125221.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22220820.1243867076510.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470092#action_12470092 ] 

Viliam Rockai commented on JBPORTAL-2309:
-----------------------------------------

i have implemented most of the phase II, but i still have few questions:

- adding a listener
how can I verify that a listener was successfully added? my current test adds a listener, then reloads a page and verifies that the listener is currently selected. no deeper logic is tested.

- error handling
this is a tricky one. i can verify that previously selected values are selected, but i guess it is not enough.

any quick ideas where can i find (so i can successfully test it) these cases?
for portal:
When the page is unavailable
When there is an error within the page
When the page is not found

for page:
When the window is unavailable 
When there is an error within the window 	
When the window is not found 




> end to end admin test for adding new portal
> -------------------------------------------
>
>                 Key: JBPORTAL-2309
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2309
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>
> As an admin,
> Portal Creation:
> Priority I:
> - create a new portal
> - add couple of page to the portal
> - add few portlets of different kinds (csm, widget, regular portlets) in each page
> - verify that new portal, pages and portlets get added correctly.
> - Make the new portal default and verify that it becomes default portal
> Priority II:
> Click on Properties under Manage Portals link
> - Verify that you can add listener
> - Different properties (dnd, partial refresh)
> - Modify error handling 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 10:41:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 1 Jun 2009 10:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6987) Disable registering
 of MC bean components as MBeans by default
In-Reply-To: <15432287.1243512657033.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25585179.1243867316591.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-6987.
--------------------------------

    Resolution: Done


Done in r89605.

> Disable registering of MC bean components as MBeans by default
> --------------------------------------------------------------
>
>                 Key: JBAS-6987
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6987
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Every MC bean that gets deployed, also gets registered as a MBean. These MBeans are optional and only provide debug information. These can by default be disabled. Refer to the referenced forum thread for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 10:51:08 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 10:51:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-6619) warnings seen during
 startup with console when populating JMS queue managed objects
In-Reply-To: <2036778.1236960202463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13171709.1243867868445.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer closed JBAS-6619.
------------------------------



> warnings seen during startup with console when populating JMS queue managed objects
> -----------------------------------------------------------------------------------
>
>                 Key: JBAS-6619
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6619
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-5.1.0.Beta1
>         Environment: r85733
>            Reporter: Charles Crouch
>            Assignee: Scott M Stark
>            Priority: Optional
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> In the server log during start up I'm seeing these warnings
> 2009-03-13 10:40:35,484 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Created name: vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml from property: name
> 2009-03-13 10:40:35,484 DEBUG [org.jboss.jms.server.destination.QueueMODefinition] (ResourceContainer.invoker.daemon-3) Creating QueueServiceMO template for: class org.jboss.jms.server.destination.QueueService
> 2009-03-13 10:40:35,515 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) ManagedObject(org.jboss.jms.server.destination.QueueServiceMO) is ManagedComponent type: @org.jboss.managed.api.annotation.ManagementComponent(type=JMSDestination, subtype=Queue)
> 2009-03-13 10:40:35,515 WARN  [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 2009-03-13 10:40:35,515 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) Created skeleton ManagedObject: ManagedObject{org.jboss.jms.server.destination.QueueServiceMO}
> 2009-03-13 10:40:35,515 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Created name: /queue/DLQ from property: JNDIName
> 2009-03-13 10:40:35,531 DEBUG [org.jboss.jms.server.destination.QueueMODefinition] (ResourceContainer.invoker.daemon-3) Creating QueueServiceMO template for: class org.jboss.jms.server.destination.QueueService
> 2009-03-13 10:40:35,531 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) ManagedObject(org.jboss.jms.server.destination.QueueServiceMO) is ManagedComponent type: @org.jboss.managed.api.annotation.ManagementComponent(type=JMSDestination, subtype=Queue)
> 2009-03-13 10:40:35,531 WARN  [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 2009-03-13 10:40:35,531 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) Created skeleton ManagedObject: ManagedObject{org.jboss.jms.server.destination.QueueServiceMO}
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Created name: /queue/ExpiryQueue from property: JNDIName
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) ID for ManagedObject: vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment, attachmentName: org.jboss.system.metadata.ServiceDeployment
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) checkForReferences, vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment has referers: null
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) Checking property: ManagedProperty{classpath,classPaths,metaType=CollectionMetaType{type=java.util.List elementType=GenericMetaType:org.jboss.managed.api.ManagedObject}
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) Checking property: ManagedProperty{name,name,metaType=SimpleMetaType:java.lang.String}
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) ManagedProperty level ID for ManagedObject: vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment, attachmentName: org.jboss.system.metadata.ServiceDeployment
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) checkForReferences, vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment has referers: null

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 10:51:07 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 10:51:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6833) warnings from
 AbstractManagedObjectPopulator printed when ManagementView.load() is called
In-Reply-To: <6769558.1240600726809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2155391.1243867867657.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6833:
-------------------------------

        Fix Version/s: JBossAS-5.2.0.Beta1
    Affects Version/s: JBossAS-5.1.0.GA


> warnings from AbstractManagedObjectPopulator printed when ManagementView.load() is called
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-6833
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6833
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When I call ManagementView.load() , I see the following warnings in the log. They don't seem to cause any harm, but it would be good to fix whatever the underlying cause is, so they don't freak out users and waste space in the log.
> 14:10:03,459 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 14:10:04,318 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 14:10:04,334 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 14:10:04,662 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 10:51:08 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 10:51:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6619) warnings seen
 during startup
 with console when populating JMS queue managed objects
In-Reply-To: <2036778.1236960202463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5983570.1243867868277.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer resolved JBAS-6619.
--------------------------------

    Resolution: Duplicate Issue


Dup of JBAS-6833.


> warnings seen during startup with console when populating JMS queue managed objects
> -----------------------------------------------------------------------------------
>
>                 Key: JBAS-6619
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6619
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-5.1.0.Beta1
>         Environment: r85733
>            Reporter: Charles Crouch
>            Assignee: Scott M Stark
>            Priority: Optional
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> In the server log during start up I'm seeing these warnings
> 2009-03-13 10:40:35,484 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Created name: vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml from property: name
> 2009-03-13 10:40:35,484 DEBUG [org.jboss.jms.server.destination.QueueMODefinition] (ResourceContainer.invoker.daemon-3) Creating QueueServiceMO template for: class org.jboss.jms.server.destination.QueueService
> 2009-03-13 10:40:35,515 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) ManagedObject(org.jboss.jms.server.destination.QueueServiceMO) is ManagedComponent type: @org.jboss.managed.api.annotation.ManagementComponent(type=JMSDestination, subtype=Queue)
> 2009-03-13 10:40:35,515 WARN  [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 2009-03-13 10:40:35,515 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) Created skeleton ManagedObject: ManagedObject{org.jboss.jms.server.destination.QueueServiceMO}
> 2009-03-13 10:40:35,515 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Created name: /queue/DLQ from property: JNDIName
> 2009-03-13 10:40:35,531 DEBUG [org.jboss.jms.server.destination.QueueMODefinition] (ResourceContainer.invoker.daemon-3) Creating QueueServiceMO template for: class org.jboss.jms.server.destination.QueueService
> 2009-03-13 10:40:35,531 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) ManagedObject(org.jboss.jms.server.destination.QueueServiceMO) is ManagedComponent type: @org.jboss.managed.api.annotation.ManagementComponent(type=JMSDestination, subtype=Queue)
> 2009-03-13 10:40:35,531 WARN  [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 2009-03-13 10:40:35,531 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectFactory] (ResourceContainer.invoker.daemon-3) Created skeleton ManagedObject: ManagedObject{org.jboss.jms.server.destination.QueueServiceMO}
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator] (ResourceContainer.invoker.daemon-3) Created name: /queue/ExpiryQueue from property: JNDIName
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) ID for ManagedObject: vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment, attachmentName: org.jboss.system.metadata.ServiceDeployment
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) checkForReferences, vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment has referers: null
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) Checking property: ManagedProperty{classpath,classPaths,metaType=CollectionMetaType{type=java.util.List elementType=GenericMetaType:org.jboss.managed.api.ManagedObject}
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) Checking property: ManagedProperty{name,name,metaType=SimpleMetaType:java.lang.String}
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) ManagedProperty level ID for ManagedObject: vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment, attachmentName: org.jboss.system.metadata.ServiceDeployment
> 2009-03-13 10:40:35,546 DEBUG [org.jboss.profileservice.management.ManagementViewImpl] (ResourceContainer.invoker.daemon-3) checkForReferences, vfsfile:/C:/usr/apps/jboss/jboss-5.1.r85733/server/default/deploy/messaging/destinations-service.xml/ServiceDeployment has referers: null

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 10:52:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 10:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6817) Add isNullable
 attribute to ManagedParameter interface
In-Reply-To: <22678848.1240427615790.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29552528.1243867976790.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6817:
-------------------------------

        Fix Version/s: JBossAS-5.2.0.Beta1
    Affects Version/s: JBossAS-5.1.0.GA
             Assignee: Emanuel Muckenhuber


> Add isNullable attribute to ManagedParameter interface
> ------------------------------------------------------
>
>                 Key: JBAS-6817
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6817
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Charles Crouch
>            Assignee: Emanuel Muckenhuber
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> See comments on JBAS-6686 for more details

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 11:15:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 11:15:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6769) 'interleaving'
 prop on connection factories and datasources has no ViewUse
In-Reply-To: <25774147.1239372696724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6895441.1243869356654.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470105#action_12470105 ] 

Ian Springer commented on JBAS-6769:
------------------------------------

This issue still exists as of r89598.


> 'interleaving' prop on connection factories and datasources has no ViewUse
> --------------------------------------------------------------------------
>
>                 Key: JBAS-6769
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6769
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Minor
>
> name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 11:18:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 11:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6769) 'interleaving' prop
 on connection factories and datasources has no ViewUse
In-Reply-To: <25774147.1239372696724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10965726.1243869536967.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6769:
-------------------------------

    Affects Version/s: JBossAS-5.1.0.GA


> 'interleaving' prop on connection factories and datasources has no ViewUse
> --------------------------------------------------------------------------
>
>                 Key: JBAS-6769
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6769
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Minor
>
> name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 11:22:56 2009
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Mon, 1 Jun 2009 11:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2309) end to end
 admin test for adding new portal
In-Reply-To: <20849835.1234456125221.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19522296.1243869776795.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470107#action_12470107 ] 

Prabhat Jha commented on JBPORTAL-2309:
---------------------------------------

What you have so far is good. 

To test the scenario where your custom error file is being used, you would have to simulate that. I think easier way would be to Hit a wrong URL with portal which is not there and asset on the page that you are getting. It should show your custom error message page. 

For listener, I would have to think. Let me get back to you on this.



> end to end admin test for adding new portal
> -------------------------------------------
>
>                 Key: JBPORTAL-2309
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2309
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>
> As an admin,
> Portal Creation:
> Priority I:
> - create a new portal
> - add couple of page to the portal
> - add few portlets of different kinds (csm, widget, regular portlets) in each page
> - verify that new portal, pages and portlets get added correctly.
> - Make the new portal default and verify that it becomes default portal
> Priority II:
> Click on Properties under Manage Portals link
> - Verify that you can add listener
> - Different properties (dnd, partial refresh)
> - Modify error handling 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 11:28:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 1 Jun 2009 11:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1633)
 MessageRedistribution example fails
In-Reply-To: <19879086.1243422057886.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8032592.1243870136563.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-1633.
--------------------------------

    Resolution: Done


> MessageRedistribution example fails
> -----------------------------------
>
>                 Key: JBMESSAGING-1633
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1633
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0 Beta
>
>
> MessageRedistribution example fails especially after doing an ant clean first. Might be intermittent.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 14:43:56 2009
From: jira-events at lists.jboss.org (Steven Crosley (JIRA))
Date: Mon, 1 Jun 2009 14:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2405) dyna.js attaches
 observer to all draggable objects
Message-ID: <23488647.1243881836546.JavaMail.jira@cloud.prod.atl2.jboss.com>

dyna.js attaches observer to all draggable objects
--------------------------------------------------

                 Key: JBPORTAL-2405
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2405
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Web
    Affects Versions: 2.7.1 Final
         Environment: OS X, Safari 3.2.1, JBoss Portal 2.7.1
            Reporter: Steven Crosley


When using Scriptaculous' Sortables functionality within a portlet, I am getting an alert message "Error 500 -- OK".

I believe the issue is that in dyna.js an observer is placed on ALL draggable objects:

Draggables.addObserver(new WindowMoveObserver());

This attempts to update the database with the portlet's region even if the DnD exists inside of a portlet.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 15:16:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 15:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6824)
 DeploymentManager.start/stop()
 fail with NoSuchDeploymentException when called on a Deployment that is a
 child of another Deployment
In-Reply-To: <29702918.1240518760377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4488113.1243883817064.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6824:
-------------------------------

        Fix Version/s: JBossAS-5.2.0.Beta1
    Affects Version/s: JBossAS-5.1.0.GA
             Priority: Minor  (was: Major)


> DeploymentManager.start/stop() fail with NoSuchDeploymentException when called on a Deployment that is a child of another Deployment
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6824
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6824
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Emanuel Muckenhuber
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> For example:
> 16:29:47,528 INFO  [DeployHandler] Stop, [vfsfile:/C:/opt/jboss-5.1.0.CR1-SNAPSHOT/server/default/deploy/jbossws.sar/jbossws-management.war/]
> 16:29:47,528 INFO  [DeployHandler] Failed to complete command: [stop] for deployment: names=[vfsfile:/C:/opt/jboss-5.1.0.CR1-SNAPSHOT/server/default/deploy/jbos
> sws.sar/jbossws-management.war/], copyContent=true
> org.jboss.profileservice.spi.NoSuchDeploymentException: Failed to find deployment in file: vfsfile:/C:/opt/jboss-5.1.0.CR1-SNAPSHOT/server/default/deploy/jbossw
> s.sar/jbossws-management.war/
>         at org.jboss.system.server.profileservice.repository.AbstractDeploymentRepository.getDeployment(AbstractDeploymentRepository.java:134)
>         at org.jboss.profileservice.management.upload.remoting.DeployHandler.scheduleStop(DeployHandler.java:156)
>         at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.stop(AbstractDeployHandler.java:307)
>         at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.stop(AbstractDeployHandler.java:296)
>         at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:181)
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:305)
>         at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.stop(StreamingDeploymentTarget.java:208)
>         at org.jboss.profileservice.management.upload.DeploymentProgressImpl.stop(DeploymentProgressImpl.java:276)
>         at org.jboss.profileservice.management.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:91)
>         at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:97)
>         at org.rhq.plugins.jbossas5.ManagedDeploymentComponent.invokeOperation(ManagedDeploymentComponent.java:129)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:484)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 15:20:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Mon, 1 Jun 2009 15:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-413)
 "security-config.dtd" and
 xsd got lost in JBoss5 binaries and at the schema location
In-Reply-To: <20395249.1243450809953.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9238871.1243884056520.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/SECURITY-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470128#action_12470128 ] 

Wolfgang Knauf commented on SECURITY-413:
-----------------------------------------

Same problem came up in the comments of this wiki article: http://www.jboss.org/community/wiki/JBossDTDs

> "security-config.dtd" and xsd got lost in JBoss5 binaries and at the schema location
> ------------------------------------------------------------------------------------
>
>                 Key: SECURITY-413
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-413
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Wolfgang Knauf
>            Assignee: Anil Saldhana
>
> JBoss 4.2.x contains "security-config.dtd" in the "docs/dtd" directory, but in 5.x the file is lost. Same for "security-config_4_0.xsd" and "security-config_4_1.xsd" in "docs/schema"
> Seems to be a result of the file being moved to a different project: https://jira.jboss.org/jira/browse/SECURITY-260
> Also, the file (and also the schemas) is no longer found at http://www.jboss.org/j2ee/dtd/security-config.dtd (which should be the schema location), came up here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=155436
> This prevents validation of "login-config.xml" files, if they are editing using e.g. Eclipse.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 15:18:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 15:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-6818) Invoking the "List All
 Subscriptions" operation from the embedded console for a Topic that has
 multiple subscribers results in an empty list being displayed
Message-ID: <24082908.1243883936597.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer closed JBAS-6818.
------------------------------



> Invoking the "List All Subscriptions" operation from the embedded console for a Topic that has multiple subscribers results in an empty list being displayed
> ------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6818
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6818
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r86689, embjopr r269
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Steps to reproduce:
> Create a new Topic. Create multiple subscribers for that Topic. Invoke the "List All Subscriptions" operation. Click on the "Show/Hide Details" link in the operations history table. The following gets displayed in the "Results" section:
> Viewing/editing of lists of PropertyDefinitionSimple properties is not yet supported. Here's the list's toString() value for now: []

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 17:20:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 1 Jun 2009 17:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1839) Implement
 POJO-based, @ManagedObject Session Metrics
In-Reply-To: <32587729.1243384676916.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9197649.1243891256733.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated EJBTHREE-1839:
------------------------------------------

    Component/s:     (was: core)
                     (was: metrics-spi)


> Implement POJO-based, @ManagedObject Session Metrics
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1839
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1839
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: metrics-deployer
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.7
>
>         Attachments: metrics.patch
>
>
> Defined by JBAS-6624.
> Consoles need Statistics accessible via ProfileService and jboss-management @ManagedObjects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 17:33:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 17:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS destinations
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23476947.1243892036802.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6783:
-------------------------------

    Summary: NPE when setting 'messageCounterHistoryDayLimit' prop on JMS destinations  (was: Allow messageCounterHistoryDayLimit to be set on JMS destinations)


> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS destinations
> -------------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Reporting this on behalf of Emanuel.
> See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 for his original comments.
> In todays meeting he mentioned you get an NPE when setting the messageCounterHistoryDayLimit  property.
> More investigation is needed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 17:41:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 17:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS destinations
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18311496.1243892516464.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6783:
-------------------------------

    Labels: EmbJopr1_3  (was: )


> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS destinations
> -------------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Reporting this on behalf of Emanuel.
> See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 for his original comments.
> In todays meeting he mentioned you get an NPE when setting the messageCounterHistoryDayLimit  property.
> More investigation is needed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 17:43:56 2009
From: jira-events at lists.jboss.org (Ben Abernathy (JIRA))
Date: Mon, 1 Jun 2009 17:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6932) Sample
 applications can't be found at JBOSS_HOME/docs/examples folder
In-Reply-To: <15062775.1242504485494.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6847673.1243892636471.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470142#action_12470142 ] 

Ben Abernathy commented on JBAS-6932:
-------------------------------------

Add 5.0.0.GA and 5.1.0.GA to the list.

> Sample applications can't be found at JBOSS_HOME/docs/examples folder
> ---------------------------------------------------------------------
>
>                 Key: JBAS-6932
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6932
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Docs/Installation and Getting Started Guide
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: JBossAS-5.0.1.GA-jdk6.zip
>            Reporter: Richard Yin
>
> In chapter 11, it says:
>  The JBoss Application Server, ships with various sample applications under JBOSS_HOME/docs/examples.
> For further details, please refer to the accompanying readme.txt for the respective sample applications under the above directory. 
> I can't find any referred applications in this folder, nor the readme.txt file. Not sure it's a packaging issue of JBossAS-5.0.1.GA jdk6 zip file.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 17:45:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 17:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS destinations
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5547098.1243892756643.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6783:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: EmbJopr1_3)


> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS destinations
> -------------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Reporting this on behalf of Emanuel.
> See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 for his original comments.
> In todays meeting he mentioned you get an NPE when setting the messageCounterHistoryDayLimit  property.
> More investigation is needed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 17:49:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 17:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-5286) Add generic
 mbeans/mcbean support into admin console
In-Reply-To: <1935713.1204912257835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16324241.1243892996687.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-5286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-5286:
-------------------------------

               Summary: Add generic mbeans/mcbean support into admin console  (was: Getting mbeans/mcbeans into open console)
     Original Estimate: 2 weeks, 2 days  (was: 3 days)
    Remaining Estimate: 2 weeks, 2 days  (was: 3 days)
         Fix Version/s: JBossAS-6.0.0.Alpha1
            Complexity: Medium


Note: this will involve adding support for dynamic resource types to the Jopr platform, which is not a trivial feature to add.


> Add generic mbeans/mcbean support into admin console
> ----------------------------------------------------
>
>                 Key: JBAS-5286
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5286
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Management services, ProfileService
>    Affects Versions: JBossAS-5.0.0.Beta4
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-6.0.0.Alpha1
>
>   Original Estimate: 2 weeks, 2 days
>  Remaining Estimate: 2 weeks, 2 days
>
> How can we get sufficient support for mbeans in the open console to drop the jmx-console.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:00:07 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:00:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-5261) Check each DS and
 Destinations properties are accurate/needed
In-Reply-To: <11075061.1204150422550.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31409795.1243893607822.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer resolved JBAS-5261.
--------------------------------

    Resolution: Done


'allocation-retry' and 'allocation-retry-wait-millis' have been added. 'interleaving' is broken on the JBAS side, so it has not been added for now.


> Check each DS and Destinations properties are accurate/needed
> -------------------------------------------------------------
>
>                 Key: JBAS-5261
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5261
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Mark Spritzler
>            Assignee: Charles Crouch
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ds_5_0.dtd, rhq-plugin.xml
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:00:08 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:00:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-5261) Check each DS and
 Destinations properties are accurate/needed
In-Reply-To: <11075061.1204150422550.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14007819.1243893608085.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer closed JBAS-5261.
------------------------------



> Check each DS and Destinations properties are accurate/needed
> -------------------------------------------------------------
>
>                 Key: JBAS-5261
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5261
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Mark Spritzler
>            Assignee: Charles Crouch
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ds_5_0.dtd, rhq-plugin.xml
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:01:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:01:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6624) EJB3 Session Bean
	metrics
In-Reply-To: <33127819.1237195628532.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6974957.1243893717833.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6624:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> EJB3 Session Bean metrics
> -------------------------
>
>                 Key: JBAS-6624
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6624
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> EJB3 Session Bean metrics (in addition to availability)
>        <!-- ear=rhq.ear,jar=rhq-enterprise-server-ejb.ejb3,name=AgentManagerBean,service=EJB3 -->
>          <!-- jboss.j2ee:jar=SimpleSLSB.jar,name=SimpleSLSB,service=EJB3 -->
>         <metric displayName="Current Count" property="CurrentSize"/>
>          <metric displayName="Create Count" property="CreateCount" displayType="summary" measurementType="trendsup"
>                  description="the number of instances of this EJB that have been created"/>
>          <metric displayName="Remove Count" property="RemoveCount" displayType="summary" measurementType="trendsup"
>                  description="the number of instances of this EJB that have been removed"/>
>          <metric displayName="Available Count" property="AvailableCount"/>
>          <metric displayName="Max Size" property="MaxSize"/>
> Plus the complex method invocation metrics
>  <metric property="InvokeStats" dataType="calltime" units="milliseconds"
>                  defaultOn="false" defaultInterval="600000" destinationType="Method Name"
>                  description="the minimum, maximum, and average invocation times for each of the methods exposed by this EJB;
>                               NOTE: this metric is only available if JBoss EJB3 RC9 Patch 1 or later is being used
>                               (a capable version of EJB3 is included with JBossAS 4.2.0.GA or later)"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:01:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6777) 'interleaving' prop
 on connection
 factories and datasources is always null, even when underlying ds.xml file
 contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18200639.1243893716725.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6777:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:03:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:03:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6625) EJB 1.x or 2.x
	metrics
In-Reply-To: <7034128.1237195628874.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12699808.1243893837080.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6625:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> EJB 1.x or 2.x metrics
> ----------------------
>
>                 Key: JBAS-6625
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6625
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB2, Management services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> EJB 1.x or 2.x Stateless Session Bean metrics (in addition to availability)
>            <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=StatelessSessionBean -->
>            <metric displayName="Create Calls"
>                    property="{stats.createCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Remove Calls"
>                    property="{stats.removeCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Method-Ready Beans"
>                    property="{stats.methodReadyCount.current}"
>                    displayType="summary"/>
>            <metric displayName="Pool Size"
>                    property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}CurrentSize}"/>
>            <metric displayName="Max Pool Size"
>                    property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}MaxSize}"/> 
> Plus the complex method invocation metrics 
>  <metric property="stats" dataType="calltime" units="milliseconds"
>                     defaultOn="false" defaultInterval="600000" destinationType="Method Name"
>                     description="the minimum, maximum, and average invocation times for each of the methods exposed by this EJB"/>
> EJB 1.x or 2.x Stateful Session Bean metrics (in addition to avail):
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=StatefulSessionBean -->
>            <metric displayName="Create Calls"
>                    description="Number of creates executed since the last time this EJB's stats were reset"
>                    property="{stats.createCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Remove Calls"
>                    description="Number of removes since the last time this EJB's stats were reset"
>                    property="{stats.removeCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Method-Ready Beans"
>                    description="The count of beans in the method-ready state"
>                    property="{stats.methodReadyCount.current}"
>                    displayType="summary"/>
>            <metric displayName="Passive Beans"
>                    description="The count of beans in the passivated state"
>                    property="{stats.passiveCount.current}"
>                    displayType="summary"/> 
> EJB 1.x or 2.x Entity Bean metrics (in addition to availability)
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=EntityBean -->
>      <metric displayName="Create Calls"
>               property="{stats.createCount.count}"
>               displayType="summary"
>               measurementType="trendsup"/>
>       <metric displayName="Remove Calls"
>               property="{stats.removeCount.count}"
>               displayType="summary"
>               measurementType="trendsup"/>
>       <metric displayName="Method-Ready Beans"
>               property="{stats.methodReadyCount.current}"
>               displayType="summary"/>
>       <metric displayName="Pooled Beans"
>               property="{stats.pooledCount.current}"
>               displayType="summary"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=cache,service=EJB}CacheSize}"
>                displayName="Cache Size"
>                defaultOn="true"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=cache,service=EJB}PassivatedCount}"
>                displayName="Passivated Count"
>                defaultOn="true"
>                measurementType="trendsup"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}PoolSize}"
>                displayName="Current Size"
>                defaultOn="true"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}MaxPoolSize}"
>                displayName="Max Size"
>                defaultOn="true"/>
> EJB 1.x or 2.x Message Driven Bean metrics (in addition to availability)
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=MessageDrivenBean -->
> <metric displayName="Create Calls"
> property="{stats.createCount.count}"
> displayType="summary"
> measurementType="trendsup"/>
> <metric displayName="Remove Calls"
> property="{stats.removeCount.count}"
> displayType="summary"
> measurementType="trendsup"/>
> <metric displayName="Method-Ready Beans"
> property="{stats.messageCount.count}"
> displayType="summary"
>               measurementType="trendsup"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:03:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:03:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30539137.1243893837390.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6808:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:03:59 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:03:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6784) Add support for JMS
 ServerPeer
 managed object to support enabling metric collection through the console
In-Reply-To: <4119905.1239740302404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16703829.1243893839080.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6784:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> Add support for JMS ServerPeer managed object to support enabling metric collection through the console
> -------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6784
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6784
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Charles Crouch
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> See 
> https://jira.jboss.org/jira/browse/JBAS-6720?focusedCommentId=12461916#action_12461916
> https://jira.jboss.org/jira/browse/JBAS-6720?focusedCommentId=12461917#action_12461917
> for more info on why this would be a good thing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:05:58 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 1 Jun 2009 18:05:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1637) Interruption
	is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13823805.1243893958159.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated JBMESSAGING-1637:
-------------------------------------

    Attachment: fix-interruption.patch


> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Tim Fox
>            Priority: Blocker
>             Fix For: 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:05:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:05:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6877) EJB3 Cache Metrics
In-Reply-To: <13995931.1241642506748.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3573919.1243893957988.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6877:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> EJB3 Cache Metrics
> ------------------
>
>                 Key: JBAS-6877
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6877
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>            Reporter: Andrew Lee Rubinger
>            Assignee: Brian Stansberry
>             Fix For: Backlog
>
>
> These statistics must be reflected in the admin-console/Jopr.
> Split from JBAS-6624:
> EJB3 Entity Tree Cache (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache-->
> <metric property="NumberOfLocksHeld" displayType="summary"/>
>          <metric property="NumberOfNodes" displayType="summary"/>
> EJB3 Entity Tree Cache Interceptor (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache,treecache-interceptor=CacheMgmtInterceptor-->
>             <metric property="HitMissRatio" displayType="summary" units="percentage"
>                     description="Returns the hit/miss ratio for the cache. This ratio is defined as hits/(hits + misses)."/>
>             <metric property="ReadWriteRatio" displayType="summary" units="percentage"
>                     description="Returns the read/write ratio for the cache. This ratio is defined as (hits + misses)/stores."/>
>             <metric property="Hits" displayType="summary"/>
>             <metric property="Misses" displayType="summary"/>
>             <metric property="Evictions" displayType="summary"/>
>             <metric property="NumberOfLocksHeld"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="AverageWriteTime" units="milliseconds"/>
>             <metric property="TimeSinceReset" units="seconds"/>
>             <metric property="AverageReadTime" units="milliseconds"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="Stores"/>
>             <metric property="NumberOfAttributes"/>
>             <metric property="ElapsedTime" units="milliseconds"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:05:57 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 1 Jun 2009 18:05:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1637) Interruption
	is busted
Message-ID: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>

Interruption is busted
----------------------

                 Key: JBMESSAGING-1637
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.3.GA, 1.4.1.GA
            Reporter: David Lloyd
            Assignee: Tim Fox
            Priority: Blocker
             Fix For: 1.4.5.GA
         Attachments: fix-interruption.patch

Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:09:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6693) Add deployExploded
 argument to DeploymentManager.distribute()
In-Reply-To: <22761801.1238177902939.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20578810.1243894196595.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6693:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> Add deployExploded argument to DeploymentManager.distribute()
> -------------------------------------------------------------
>
>                 Key: JBAS-6693
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6693
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Charles Crouch
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> It would be helpful if we could tell the DeploymentManager to expand the archive when its deployed, since linked issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:09:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:09:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6979)
 org.jboss.dependency.spi.ControllerState class (from jboss-dependency.jar)
 required by remote Profile Service client calling
 ManagementView.getDeployment()
In-Reply-To: <28592167.1243393316467.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3158039.1243894197106.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6979:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> org.jboss.dependency.spi.ControllerState class (from jboss-dependency.jar) required by remote Profile Service client calling ManagementView.getDeployment()
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6979
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6979
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>
> I'm assuming this class should not be required by a remote client.
> Here's the stack trace:
> 2009-05-26 22:41:31,357 WARN  [InventoryManager.discovery-1] (rhq.core.pc.inventory.InventoryManager)- Failure during discovery for [EJB3 JAR] Resources - failed after 156 ms.
> java.lang.Exception: Discovery component invocation failed.
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:248)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NoClassDefFoundError: org/jboss/dependency/spi/ControllerState
> 	at org.jboss.profileservice.spi.types.ControllerStateMetaType.<init>(ControllerStateMetaType.java:53)
> 	at org.jboss.profileservice.spi.types.ControllerStateMetaType.<clinit>(ControllerStateMetaType.java:49)
> 	at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> 	at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> 	at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> 	at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
> 	at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
> 	at java.lang.reflect.Field.getLong(Field.java:528)
> 	at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1614)
> 	at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
> 	at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:413)
> 	at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.managed.plugins.DefaultFieldsImpl.readObject(DefaultFieldsImpl.java:378)
> 	at sun.reflect.GeneratedMethodAccessor380.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.managed.plugins.ManagedPropertyImpl.readVersion1(ManagedPropertyImpl.java:652)
> 	at org.jboss.managed.plugins.ManagedPropertyImpl.readObject(ManagedPropertyImpl.java:626)
> 	at sun.reflect.GeneratedMethodAccessor379.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at AOPProxy$1.getDeployment(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.AbstractManagedDeploymentDiscoveryComponent.discoverResources(AbstractManagedDeploymentDiscoveryComponent.java:86)
> 	at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
> 	... 5 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.dependency.spi.ControllerState
> 	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 org.rhq.core.pc.plugin.ChildFirstPluginClassLoader.loadClass(ChildFirstPluginClassLoader.java:68)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> 	... 87 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:09:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 1 Jun 2009 18:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1637) Interruption
	is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18275530.1243894196766.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1637:
-----------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


Howard, can you take a look please?

> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:11:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:11:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6984) trying to remotely
 retrieve
 statistic properties (e.g. rollbackCount) from MCBean:JTA managed
 components results in "ClassNotFoundException:
 com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
In-Reply-To: <11628190.1243511107980.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26434668.1243894317257.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6984:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> trying to remotely retrieve statistic properties (e.g. rollbackCount) from MCBean:JTA managed components results in "ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6984
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6984
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>
> 2009-05-28 07:40:01,544 ERROR [ResourceContainer.invoker.daemon-364] (org.rhq.plugins.jbossas5.ApplicationServerComponent)- Failed to obtain metric 'MCBean|JTA|*|rollbackCount'.
> java.lang.IllegalStateException: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:160)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
> 	at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
> 	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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> 	at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1462)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1312)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	... 11 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:11:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6980)
 "ClassNotFoundException:
 org.jboss.aop.instrument.Untransformable" occurs when
 ManagementView.getComponentsForType(<MBean:WebApplication>) is called from
 a remote client
In-Reply-To: <15938916.1243426198456.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17370238.1243894316748.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6980:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> "ClassNotFoundException: org.jboss.aop.instrument.Untransformable" occurs when ManagementView.getComponentsForType(<MBean:WebApplication>) is called from a remote client
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6980
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6980
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>
> Note, this occurs even though I have jboss-aop-client.jar, which contains org.jboss.aop.instrument.Untransformable, in my client's classpath. Here's the stack trace:
> 2009-05-27 07:54:31,035 WARN  [InventoryManager.discovery-1] (rhq.core.pc.inventory.InventoryManager)- Failure during discovery for [Embedded Web Application Context] Resources - failed after 250 ms.
> java.lang.Exception: Discovery component invocation failed.
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:248)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.IllegalStateException: org.jboss.remoting.InvocationFailureException: Unable to perform invocation; nested exception is: 
> 	java.lang.RuntimeException: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:160)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:141)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.getWebApplicationComponents(WebApplicationContextDiscoveryComponent.java:182)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.discoverResources(WebApplicationContextDiscoveryComponent.java:90)
> 	at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
> 	... 5 more
> Caused by: org.jboss.remoting.InvocationFailureException: Unable to perform invocation; nested exception is: 
> 	java.lang.RuntimeException: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:142)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:891)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	... 12 more
> Caused by: java.lang.RuntimeException: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at org.jboss.aop.proxy.MarshalledInterfaceProxy.readResolve(MarshalledInterfaceProxy.java:76)
> 	at sun.reflect.GeneratedMethodAccessor973.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:141)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.getWebApplicationComponents(WebApplicationContextDiscoveryComponent.java:182)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.discoverResources(WebApplicationContextDiscoveryComponent.java:90)
> 	at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	... 19 more
> Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at javassist.ClassPool.toClass(ClassPool.java:1035)
> 	at javassist.scopedpool.ScopedClassPool.toClass(ScopedClassPool.java:306)
> 	at javassist.CtClass.toClass(CtClass.java:1094)
> 	at org.jboss.aop.instrument.TransformerCommon$ToClassAction$2.toClass(TransformerCommon.java:331)
> 	at org.jboss.aop.instrument.TransformerCommon.toClass(TransformerCommon.java:139)
> 	at org.jboss.aop.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:126)
> 	at org.jboss.aop.proxy.ProxyFactory.createInterfaceProxy(ProxyFactory.java:96)
> 	at org.jboss.aop.proxy.MarshalledInterfaceProxy.readResolve(MarshalledInterfaceProxy.java:72)
> 	at sun.reflect.GeneratedMethodAccessor973.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	... 19 more
> Caused by: java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
> 	at sun.reflect.GeneratedMethodAccessor974.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at javassist.ClassPool.toClass2(ClassPool.java:1047)
> 	at javassist.ClassPool.toClass(ClassPool.java:1029)
> 	... 82 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.aop.instrument.Untransformable
> 	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)
> 	... 89 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 18:11:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 1 Jun 2009 18:11:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6982) unable to connect to
 Profile Service remotely using EJB remote interface
In-Reply-To: <33034814.1243442816774.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17317938.1243894317047.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6982:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> unable to connect to Profile Service remotely using EJB remote interface
> ------------------------------------------------------------------------
>
>                 Key: JBAS-6982
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6982
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>
> The non-EJB remote interface is working, with the exception of the various class loading exceptions. The EJB interface is not, due to an authentication failure, but I think it used to work.
> Here's the log output showing me doing the JNDI lookup of the EJB proxies:
> DEBUG 27-05 12:40:03,988 (RemoteProfileServiceConnectionProvider.java:doConnect:90)  -Connecting to Profile Service via remote JNDI using env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:03,988 (AbstractProfileServiceConnectionProvider.java:createInitialContext:74)  -Creating JNDI InitialContext with env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:04,004 (Logger.java:debug:228)  -Using ThreadLocal: false
> DEBUG 27-05 12:40:04,035 (AbstractProfileServiceConnectionProvider.java:createInitialContext:83)  -Created JNDI InitialContext [javax.naming.InitialContext at 1ccb029].
> DEBUG 27-05 12:40:04,035 (Logger.java:debug:228)  -createSocket, hostAddr: /127.0.0.1, port: 1099, localAddr: null, localPort: 0, timeout: 0
> DEBUG 27-05 12:40:04,191 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureProfileService/remote
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Encrypted Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -removed SocketClientInvoker[3820e, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -Created Proxy of type $Proxy1 for EJB3 Business Interface: org.jboss.profileservice.spi.ProfileService
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureManagementView/remote
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -removed SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Created Proxy of type $Proxy3 for EJB3 Business Interface: org.jboss.deployers.spi.management.ManagementView
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureDeploymentManager/remote
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -removed SocketClientInvoker[12940b3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Created Proxy of type $Proxy5 for EJB3 Business Interface: org.jboss.deployers.spi.management.deploy.DeploymentManager
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Couldn't handle invocation directly within org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8: Current invocation "public abstract boolean org.jboss.deployers.spi.management.ManagementView.load()" is not eligible for direct handling by org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Received invocation request to method org.jboss.deployers.spi.management.ManagementView: org.jboss.deployers.spi.management.ManagementView.load(); using hash: -657996635075089079
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -removed SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] disconnecting ...
> And here's the "EJBAccessException: Caller unauthorized" that occurs when I call load() on the ManagementView proxy:
> Exception in thread "main" javax.ejb.EJBAccessException: Caller unauthorized
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:199)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         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:524)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 22:58:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Mon, 1 Jun 2009 22:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-84) Set a default MO.name
 to the MO.componentName
Message-ID: <9292835.1243911536683.JavaMail.jira@cloud.prod.atl2.jboss.com>

Set a default MO.name to the MO.componentName
---------------------------------------------

                 Key: JBMAN-84
                 URL: https://jira.jboss.org/jira/browse/JBMAN-84
             Project: JBoss Managed
          Issue Type: Feature Request
          Components: managedobject
            Reporter: Scott M Stark
            Assignee: Scott M Stark
             Fix For:  JBossMan.2.1.1.Beta1


If a ManagedObject has a defaulted name, the name should be set to the ManagedObject.componentName if one exists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 23:10:06 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Mon, 1 Jun 2009 23:10:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-84) Set a default
 MO.name to the MO.componentName
In-Reply-To: <9292835.1243911536683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19615348.1243912206809.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMAN-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBMAN-84.
--------------------------------

    Resolution: Done


> Set a default MO.name to the MO.componentName
> ---------------------------------------------
>
>                 Key: JBMAN-84
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-84
>             Project: JBoss Managed
>          Issue Type: Feature Request
>          Components: managedobject
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For:  JBossMan.2.1.1.Beta1
>
>
> If a ManagedObject has a defaulted name, the name should be set to the ManagedObject.componentName if one exists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 23:21:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 1 Jun 2009 23:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-75) Allow for shutdown
 to interrupt startup
In-Reply-To: <28571693.1242320326783.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17743846.1243912916458.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-75.
---------------------------------------

    Fix Version/s: 2.0.0-alpha-1
                       (was: Unscheduled)
       Resolution: Done


> Allow for shutdown to interrupt startup
> ---------------------------------------
>
>                 Key: JBBOOT-75
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-75
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-base
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-alpha-1
>
>
> Both startup and shutdown block on the same "this" reference, meaning that the server may not be shutdown until startup is complete.  As DML advises, use an interrupt mechanism to allow another Thread to interrupt startup.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 23:21:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 1 Jun 2009 23:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6974) Ensure the Shutdown
 Hook fully shuts down the Server
In-Reply-To: <20457385.1243304636427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20824571.1243912916595.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBAS-6974:
--------------------------------------

    Attachment:     (was: JBAS-6974.patch)


> Ensure the Shutdown Hook fully shuts down the Server
> ----------------------------------------------------
>
>                 Key: JBAS-6974
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6974
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Shutdown Hook is not calling full shutdown before the process exits.
> For starters, there's this:
> if (currentState.equals(LifecycleState.STARTED) || currentState.equals(LifecycleState.STARTING))
> Find other possible problems and ensure the lifecycle goes through full shutdown before the VM can terminate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  1 23:28:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 1 Jun 2009 23:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6974) Ensure the Shutdown
 Hook fully shuts down the Server
In-Reply-To: <20457385.1243304636427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5564546.1243913336785.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBAS-6974:
--------------------------------------

    Attachment: JBAS-6974.patch


> Ensure the Shutdown Hook fully shuts down the Server
> ----------------------------------------------------
>
>                 Key: JBAS-6974
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6974
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: JBAS-6974.patch
>
>
> Shutdown Hook is not calling full shutdown before the process exits.
> For starters, there's this:
> if (currentState.equals(LifecycleState.STARTED) || currentState.equals(LifecycleState.STARTING))
> Find other possible problems and ensure the lifecycle goes through full shutdown before the VM can terminate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 02:18:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 2 Jun 2009 02:18:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6624) EJB3 Session Bean
	metrics
In-Reply-To: <33127819.1237195628532.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10850307.1243923537225.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470167#action_12470167 ] 

Andrew Lee Rubinger commented on JBAS-6624:
-------------------------------------------

I've added the jboss-ejb3-metrics-deployer into the AS Build in JBPAPP_5_0 in r89649.

At this point only minor changes to the mappings should be left; I'll wait to hear requests from the JON team.

> EJB3 Session Bean metrics
> -------------------------
>
>                 Key: JBAS-6624
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6624
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> EJB3 Session Bean metrics (in addition to availability)
>        <!-- ear=rhq.ear,jar=rhq-enterprise-server-ejb.ejb3,name=AgentManagerBean,service=EJB3 -->
>          <!-- jboss.j2ee:jar=SimpleSLSB.jar,name=SimpleSLSB,service=EJB3 -->
>         <metric displayName="Current Count" property="CurrentSize"/>
>          <metric displayName="Create Count" property="CreateCount" displayType="summary" measurementType="trendsup"
>                  description="the number of instances of this EJB that have been created"/>
>          <metric displayName="Remove Count" property="RemoveCount" displayType="summary" measurementType="trendsup"
>                  description="the number of instances of this EJB that have been removed"/>
>          <metric displayName="Available Count" property="AvailableCount"/>
>          <metric displayName="Max Size" property="MaxSize"/>
> Plus the complex method invocation metrics
>  <metric property="InvokeStats" dataType="calltime" units="milliseconds"
>                  defaultOn="false" defaultInterval="600000" destinationType="Method Name"
>                  description="the minimum, maximum, and average invocation times for each of the methods exposed by this EJB;
>                               NOTE: this metric is only available if JBoss EJB3 RC9 Patch 1 or later is being used
>                               (a capable version of EJB3 is included with JBossAS 4.2.0.GA or later)"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 02:22:56 2009
From: jira-events at lists.jboss.org (Greg Barton (JIRA))
Date: Tue, 2 Jun 2009 02:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2101) Intermittant
 NullPointerException when invoking StatefulSession.asyncUpdate() while
 maintainTms==true
Message-ID: <27736937.1243923776508.JavaMail.jira@cloud.prod.atl2.jboss.com>

Intermittant NullPointerException when invoking StatefulSession.asyncUpdate() while maintainTms==true
-----------------------------------------------------------------------------------------------------

                 Key: JBRULES-2101
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2101
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
         Environment: Ubuntu Jaunty Jackelope
Linux version 2.6.27-11-generic (buildd at yellow) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) ) #1 SMP Wed Apr 1 20:53:41 UTC 2009
Multicore 
            Reporter: Greg Barton
            Assignee: Mark Proctor


After calling StatefulSession.asyncUpdate() the following exception occurs, but only when maintainTms==true in the rule configuration:

Exception in thread "Thread-5" java.lang.NullPointerException                                                                                       
        at org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1387)                                                          
        at org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1350)                                                          
        at org.drools.concurrent.UpdateObject.execute(UpdateObject.java:46)                                                                         
        at org.drools.concurrent.CommandExecutor.run(CommandExecutor.java:78)                                                                       
        at java.lang.Thread.run(Thread.java:619) 

AbstractWorkingMemory.java line 1387 is wrapped in an if statement with condition "this.maintainTms" so setting maintainTms=false avoids the exception entirely.  The NPE producing line is this:

status = ((InternalFactHandle) factHandle).getEqualityKey().getStatus();

While encountering this problem the factHandle passed in to StatefulSession.asyncUpdate() was always non-null, so my guess is that the getEqualityKey() call returned null.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 02:53:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 2 Jun 2009 02:53:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1637)
	Interruption is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28774218.1243925637180.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470170#action_12470170 ] 

Howard Gao commented on JBMESSAGING-1637:
-----------------------------------------

Hi David,

In your patch:

     boolean intr = Thread.interrupted();
     for (;;) try
     {
        lock.readLock().acquire();
        break;
     }
    catch (InterruptedException ex)
     {
        intr = true;
     }

I don't understand why in JBM needs to reset the interrupted state of the calling thread. My reason:

1. If the thread is interrupted by someone, JBM assumes no responsibility of resetting it. The interrupter should know of the consequence of his action and be prepared for any exceptions caused by this interruption. Actually this code may produce an effect that against the will of the interrupter, see the following comment from JBAS-6546:

...To avoid a rogue plugin degrading the plugin container performance as a whole, the plugin container invokes plugin component methods via a thread pool/future/timeout mechanism - if a plugin component's facet method takes too long to complete, a timeout will trigger, the plugin container will abort and the thread will be interrupted.

So if the above code is applied, it possible that the thread will wait there for long even if the caller has interrupted it. 


2. The acquire() method's InterruptedException indicates a failure of acquiring the lock, nothing more nothing less. We can't assume too much about the internal impl of this method. If in an environment we're having problem in getting synchronization, then it is a good reason JBM throws exception notifying any interested party that JBM is not able to work properly under such a condition. 

wdyt?

Howard


> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 05:16:04 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 2 Jun 2009 05:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1637) Interruption
	is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25747193.1243934164593.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1637:
---------------------------------

    Priority: Major  (was: Blocker)


> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>             Fix For: 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 05:24:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 2 Jun 2009 05:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1637)
	Interruption is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28462668.1243934696791.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470188#action_12470188 ] 

Tim Fox commented on JBMESSAGING-1637:
--------------------------------------

Where does this originally come from?

I'm guessing it's because the new AS console has a (new) requirement that all component operations need to be interruptible? If so, we can deal with that, but I wouldn't expect all operations, especially in the older 1.x code base to allow ops to be interrupted.

We've never made the claim that our operations are interruptible.

> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>             Fix For: 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 05:55:08 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Tue, 2 Jun 2009 05:55:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Admin Join problem
 -GMS flush by coordinator failed
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8822685.1243936508210.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470193#action_12470193 ] 

Vladimir Blagojevic commented on JGRP-985:
------------------------------------------

I am trying to reproduce this issue on my local machine using JGroups2.8.0Alpha3 and I am unable to do so. I have augmented your test locally not to execute getState and I have used default flush-udp.xml instead of your jgroups.xml since yours does not include UNICAST protocol. To be honest, I do see a couple of timeouts and attempted rejoins but they all eventually succeed. I used three terminals and I cycled through them just as you described for about 10 minutes.



> Admin  Join problem -GMS flush by coordinator failed
> ----------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 06:23:56 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 2 Jun 2009 06:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-442) Aggregate
 the respective API docs
In-Reply-To: <1566030.1242724505227.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20937335.1243938236429.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMICROCONT-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470194#action_12470194 ] 

Thomas Diesler commented on JBMICROCONT-442:
--------------------------------------------

Jason sais

All of our code, especially SPI or API classes must have javadoc which explains in detail the following things:

1) How the module is supposed to be used (and how it is actually used if known)
2) The intended behaviour, and any aspect of it that is known to be broken or a hack (so that someone can differentiate between a design problem and just an unimplemented section that needs to be fixed)
3) Critical preconditions (e.g. "this class expects that the same vfs handle instance be reused during a redeploy")
4) Thread-access design (e.g. "this class is thread-safe and can be accessed from multiple threads", "this class is not thread-safe, and all callers must use a shared lock to access", "this class is intended to have an instance-per-thread")


> Aggregate the respective API docs
> ---------------------------------
>
>                 Key: JBMICROCONT-442
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-442
>             Project: JBoss Microcontainer
>          Issue Type: Task
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: JBossMC-2.0.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 06:32:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 2 Jun 2009 06:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1840) StrictMaxPool
 does not
 maintain a correct "inUse" count leading to incorrect reporting of
 "AvailableCount"
In-Reply-To: <742346.1243851896474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28656239.1243938776599.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1840.
------------------------------------

                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-core:1.1.7


StrictMaxPool has been fixed to avoid decrementing the inUse counter multiple times for the same context

> StrictMaxPool does not maintain a correct "inUse" count leading to incorrect reporting of "AvailableCount"
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1840
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1840
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.6
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> The org.jboss.ejb3.test.stateless.unit.MetricsUnitTestCase shows a failure w.r.t the "AvailableCount" of a bean marked with StrictMaxPool. 
> The StrictMaxPool internally implements the getAvailableCount() as follows:
>    public int getAvailableCount()
>    {
>       return maxSize - inUse;
>    }
> The "inUse" count is handled incorrectly in the discard and remove method of this pool leading to that count reaching a negative value. Ultimately, this leads to incorrect available count being reported.
> When an exception occurs, the bean is discarded from the pool. This leads to a call on discard method of the StrictMaxPool which decrements the inUse count and then calls the remove method which *again* decrements the inUse count for the same bean context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 06:32:56 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 2 Jun 2009 06:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6994) Improve developer
	javadoc
Message-ID: <32936935.1243938776460.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve developer javadoc
-------------------------

                 Key: JBAS-6994
                 URL: https://jira.jboss.org/jira/browse/JBAS-6994
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Other
            Reporter: Thomas Diesler
             Fix For: JBossAS-6.0.0.Alpha1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 06:32:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 2 Jun 2009 06:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1840) StrictMaxPool
 does not
 maintain a correct "inUse" count leading to incorrect reporting of
 "AvailableCount"
In-Reply-To: <742346.1243851896474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16196879.1243938776712.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470197#action_12470197 ] 

jaikiran pai commented on EJBTHREE-1840:
----------------------------------------

org/jboss/ejb3/test/stateless/unit/MetricsUnitTestCase in ejb3-testsuite has the necessary tests.


> StrictMaxPool does not maintain a correct "inUse" count leading to incorrect reporting of "AvailableCount"
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1840
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1840
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.6
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> The org.jboss.ejb3.test.stateless.unit.MetricsUnitTestCase shows a failure w.r.t the "AvailableCount" of a bean marked with StrictMaxPool. 
> The StrictMaxPool internally implements the getAvailableCount() as follows:
>    public int getAvailableCount()
>    {
>       return maxSize - inUse;
>    }
> The "inUse" count is handled incorrectly in the discard and remove method of this pool leading to that count reaching a negative value. Ultimately, this leads to incorrect available count being reported.
> When an exception occurs, the bean is discarded from the pool. This leads to a call on discard method of the StrictMaxPool which decrements the inUse count and then calls the remove method which *again* decrements the inUse count for the same bean context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 06:34:56 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 2 Jun 2009 06:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6994) Improve developer
	javadoc
In-Reply-To: <32936935.1243938776460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1597390.1243938896365.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated JBAS-6994:
---------------------------------

    Description: 
Jason sais

The javadoc/code comments in our core modules are VERY lacking, so it is incredibly difficult for new folks to understand how anything is supposed to work (I have been hearing some groaning about this recently).

All of our code, especially SPI or API classes must have javadoc which explains in detail the following things:

1) How the module is supposed to be used (and how it is actually used if known)
2) The intended behavior, and any aspect of it that is known to be broken or a hack (so that someone can differentiate between a design problem and just an unimplemented section that needs to be fixed)
3) Crticial preconditions (e.g. "this class expects that the same vfs handle instance be reused during a redeploy")
4) Thread-access design (e.g. "this class is thread-safe and can be accessed from multiple threads", "this class is not thread-safe, and all callers must use a shared lock to access", "this class is intended to have an instance-per-thread")

If we can't answer these simple questions, then it is likely our design is flawed.



> Improve developer javadoc
> -------------------------
>
>                 Key: JBAS-6994
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6994
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Thomas Diesler
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Jason sais
> The javadoc/code comments in our core modules are VERY lacking, so it is incredibly difficult for new folks to understand how anything is supposed to work (I have been hearing some groaning about this recently).
> All of our code, especially SPI or API classes must have javadoc which explains in detail the following things:
> 1) How the module is supposed to be used (and how it is actually used if known)
> 2) The intended behavior, and any aspect of it that is known to be broken or a hack (so that someone can differentiate between a design problem and just an unimplemented section that needs to be fixed)
> 3) Crticial preconditions (e.g. "this class expects that the same vfs handle instance be reused during a redeploy")
> 4) Thread-access design (e.g. "this class is thread-safe and can be accessed from multiple threads", "this class is not thread-safe, and all callers must use a shared lock to access", "this class is intended to have an instance-per-thread")
> If we can't answer these simple questions, then it is likely our design is flawed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 07:20:57 2009
From: jira-events at lists.jboss.org (John Hornsby (JIRA))
Date: Tue, 2 Jun 2009 07:20:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6995) portlet fails to
 start in liferay 5.2.3 Jboss 5.0.0 bundle but no errors
Message-ID: <18535326.1243941657598.JavaMail.jira@cloud.prod.atl2.jboss.com>

portlet fails to start in liferay 5.2.3 Jboss 5.0.0 bundle but no errors
------------------------------------------------------------------------

                 Key: JBAS-6995
                 URL: https://jira.jboss.org/jira/browse/JBAS-6995
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.0.0.GA
         Environment: Win Vista (also tried Win XP, and Ubuntu Linux), Java jdk1.5.0_07 (also tried java jdk1.6.0_02), Using HSQLDB.   Same problem using the liferay-portal-jboss-tomcat-5.0-5.2.3.zip and the liferay-portal-jboss-tomcat-5.0-5.2.2.zip bundles.
The portlet works successfully in liferay_tomcat bundles.
            Reporter: John Hornsby


Problems deploying portlet successfully.   The auto-deployment appears to work OK (there are no errors in any log) but it doesn't start up and doesn't appear in the Add Applications dialogue in Liferay:

10:00:05,753 INFO  [STDOUT]   Expanding: C:\LR523\deploy\konakartadmin.war into C:\Users\John\AppData\Local\Temp\20090602100005480
10:00:11,931 INFO  [STDOUT]   Copying 1 file to C:\Users\John\AppData\Local\Temp\20090602100005480\WEB-INF\classes
10:00:13,219 INFO  [STDOUT]   Warning: META-INF\MANIFEST.MF modified in the future.
10:00:13,560 INFO  [STDOUT]   Copying 149 files to C:\LR523\jbt\server\default\deploy\konakartadmin.war
10:00:17,393 INFO  [STDOUT]   Copying 1 file to C:\LR523\jbt\server\default\deploy\konakartadmin.war
10:00:18,027 INFO  [STDOUT]   Deleting directory C:\Users\John\AppData\Local\Temp\20090602100005480
10:00:23,125 INFO  [STDOUT] 10:00:23,124 INFO  [PortletAutoDeployListener] Portlets for C:\LR523\deploy\konakartadmin.war copied successfully. Deployment will start in a few seconds.
10:01:00,269 INFO  [TomcatDeployment] deploy, ctxPath=/konakartadmin, vfsUrl=konakartadmin.war

After the "Deployment will start in a few seconds." I would expect to see the service actually start but it doesn't.  No clues as to why appear in the server .log, which actually reports that the war is fully deployed:

2009-06-02 10:55:53,745 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner) Initialized: {WebApplication: /C:/LR523/jbt/server/default/deploy/konakartadmin.war/, URL: vfsfile:/C:/LR523/jbt/server/default/deploy/konakartadmin.war/, classLoader: BaseClassLoader at 13c92ad{vfsfile:/C:/LR523/jbt/server/default/deploy/konakartadmin.war/}:20746925} jboss.web:j2eeType=WebModule,name=//localhost/konakartadmin,J2EEApplication=none,J2EEServer=none
2009-06-02 10:55:53,750 DEBUG [org.jboss.deployers.plugins.deployers.DeployersImpl] (HDScanner) Fully Deployed vfsfile:/C:/LR523/jbt/server/default/deploy/konakartadmin.war/

When I shut JBoss down it tells me that the services (defined in my war) were not started:

10:49:13,352 INFO  [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[FileUpload] has not been started
10:49:13,373 INFO  [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[jsp] has not been started
10:49:13,393 INFO  [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[default] has not been started
10:49:13,412 INFO  [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[kk_admin_portlet] has not been started
10:49:13,433 INFO  [ContainerBase] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/konakartadmin].[KonaKartAdminServlet] has not been started


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 09:22:57 2009
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Tue, 2 Jun 2009 09:22:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6983) Error configuring
 property: sessionIdAlphabet for WarDeployer
In-Reply-To: <16967894.1243494296657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4399899.1243948977113.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remy Maucherat reassigned JBAS-6983:
------------------------------------

    Assignee: Brian Stansberry  (was: Remy Maucherat)


Yes, looking at the code, there is a problem with this flag.

This is apparently mapped to a server wide property, and it is set using a service specific property. It could be set using a system property instead. Either way, it needs some modifications. An additional consideration is that Tomcat never had a session id alphabet flag. Probably the broken mobile browsers got fixed. Is there still a real need for that ?

Assign to Brian to look at the options.

> Error configuring property: sessionIdAlphabet for WarDeployer
> -------------------------------------------------------------
>
>                 Key: JBAS-6983
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6983
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: JBoss 5.0.1.GA or JBoss 5.1.0.GA
>            Reporter: Manuel Aznar Perez
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> At "server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml" when i uncomment "<property name="sessionIdAlphabet">" and run JBoss. Launch exception:
> 2009-05-28 08:34:34,670 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Configured: name=WarDeployer state=Instantiated
> java.lang.RuntimeException: Error configuring property: sessionIdAlphabet for WarDeployer
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112)
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85)
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44)
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
>         at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
>         at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
>         at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> That is because don't have "jboss-web-service.jar" in deployer. 
> This jar is in "deploy/jbossweb.sar".
> This is fixed copy jar file to deployer directory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 09:43:03 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 2 Jun 2009 09:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-201) Provide a
 validator to check
 for the presence of atleast one business interface on a EJB3 bean
In-Reply-To: <12119065.1242889616485.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30631023.1243950183269.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBMETA-201.
---------------------------------

    Resolution: Done


Done in r89668

> Provide a validator to check for the presence of atleast one business interface on a EJB3 bean
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-201
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-201
>             Project: JBoss Metadata
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> Provide a validator which validates that the EJB3 bean exposes atleast one business interface.
> Please see the referenced forum thread for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 09:43:03 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 2 Jun 2009 09:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-201) Provide a validator
 to check for
 the presence of atleast one business interface on a EJB3 bean
In-Reply-To: <12119065.1242889616485.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26553484.1243950183464.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated JBMETA-201:
--------------------------------

    Fix Version/s: 1.0.2.Beta1


> Provide a validator to check for the presence of atleast one business interface on a EJB3 bean
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-201
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-201
>             Project: JBoss Metadata
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.0.2.Beta1
>
>
> Provide a validator which validates that the EJB3 bean exposes atleast one business interface.
> Please see the referenced forum thread for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 10:06:57 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 2 Jun 2009 10:06:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1637)
	Interruption is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4765460.1243951617497.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470237#action_12470237 ] 

David Lloyd commented on JBMESSAGING-1637:
------------------------------------------

Tim, being able to handle interruption is not optional, something that you support or don't support.  When you run in a container it's just a matter of time before something trips the interrupt status - your caller might use it, or a callee might use it.  Not supporting interruption is a bug.  My patch simply adopts a policy of deferring the interrupt in a safe manner, which fixes the bug.  Now if you want interruption to prematurely cancel an event in a clean way, that is a feature that you are free to implement if you wish.

Howard, in response to 1., *everyone* that invokes an interruptible operation has the responsibility of resetting the interrupted status.  If there is no sane way to handle interruption (because, for example, someone thought it might be a good idea to throw Exception from a method), then the only other option is to ignore it but *preserve* the flag setting, so the caller has a chance to handle it.  Yes, this means that things may keep running after interruption.  But this is what your options are unless you're willing to go through and strip out all those "throws Exceptions", replace them with "throws InterruptedException, XxxxException, ..." *and* locate all the call sites and remove *their* "catch (Exception e)" and replace them with interrupt-aware handlers, and *then* go through and apply sane interrupt handling to all those call sites.

The goal here isn't to make JBM interruptible - that would be a lot more work - but to fix the bug that it has no strategy whatsoever to handle interruption, resulting in all kinds of possible problems.  If JBM was using j.u.c instead of oswego, I would have simply replaced the lock calls with uninterruptible lock calls.

As for (2), you are incorrect.  InterruptedException indicates that the thread was interrupted while acquiring the lock.  As I've said many times before, when you invoke an operation that can throw InterruptedException, your choices are to preserve the interrupt status and retry the operation, preserve interrupt status and throw some other exception, or rethrow InterruptedException itself *after* correctly handing the interrupt situation by aborting what you're doing in a clean manner (whether that be rolling back your operation or whatever).  Since JBM 1.x was obviously not designed with interruption in mind, the first option is the safest.  You may disagree and decide to go ahead and refactor all these methods and their call sites.  But remember this.  Any operation which throws InterruptedException should be *retryable* (in other words, you must give the caller the opportunity to decide whether they care that an operation was interrupted - maybe they don't and they want to retry it anyway).  If you make your operation interruptible and it is not retryable, you should not be throwing InterruptedException, but instead, re-set the interrupt status of the current thread and throw some other exception.

> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>             Fix For: 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Tue Jun  2 10:08:58 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 2 Jun 2009 10:08:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <29694520.1243951738548.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470238#action_12470238 ] 

Howard Gao commented on JBMESSAGING-1631:
-----------------------------------------

Hi Victor,

I wrote up a test case that looks like that:

1) Start up a two-node jbm cluster, messaging-node0 and messaging-node1. A distributed queue also deployed.
2) Deploy a MDB jar to messaging-node0/farm. The MDB receives messages from the distributed queue.
3) Start a message sending application and send the messages over ClusteredConnectionFactory. The messages will be sent to the two node in round-robin fashion.

I got it run on one machine. However, to be able to reproduce the issue, I think I need to deploy the cluster to two machines.

If you got a chance, can you comment on whether my test is suitable or not? Thanks. I'll update you once I got it run over certain time.

Howard



> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: logs-and-config-prod.zip, logs-and-config-test.zip
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 11:11:56 2009
From: jira-events at lists.jboss.org (Ben Abernathy (JIRA))
Date: Tue, 2 Jun 2009 11:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1841) Improve logging
 for InterceptorsFactory warning
Message-ID: <17265944.1243955516468.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve logging for InterceptorsFactory warning
-----------------------------------------------

                 Key: EJBTHREE-1841
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1841
             Project: EJB 3.0
          Issue Type: Task
    Affects Versions: AS 5.0.0.CR1
         Environment: Windows XP 32-bit, JBoss AS 5.1.0GA
            Reporter: Ben Abernathy


Every time this section of code is called, the following warning is displayed:

09:02:34,655 WARN  [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container

Upon inspecting EJBTHREE-1246, it appears this warning can be ignored by bean developers. If that is the case, is it necessary to fill up the console and log with benign warnings? There can be lots of these if the application is large.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 11:44:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 2 Jun 2009 11:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-85) Don't override the
 @ManagementObjectID with a default name.
Message-ID: <21603131.1243957496670.JavaMail.jira@cloud.prod.atl2.jboss.com>

Don't override the @ManagementObjectID with a default name.
-----------------------------------------------------------

                 Key: JBMAN-85
                 URL: https://jira.jboss.org/jira/browse/JBMAN-85
             Project: JBoss Managed
          Issue Type: Bug
    Affects Versions:  JBossMan.2.1.1.Beta1
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber
             Fix For: JBossMan.2.1.1.Beta2


The ManagedObject.hasDefaultName needs to be set to false when setting a @ManagementObjectID, otherwise the default name will be used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 11:44:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 2 Jun 2009 11:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-85) Don't override the
 @ManagementObjectID with a default name.
In-Reply-To: <21603131.1243957496670.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12115838.1243957496798.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMAN-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved JBMAN-85.
--------------------------------------

    Resolution: Done


 Revision: 89669

> Don't override the @ManagementObjectID with a default name.
> -----------------------------------------------------------
>
>                 Key: JBMAN-85
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-85
>             Project: JBoss Managed
>          Issue Type: Bug
>    Affects Versions:  JBossMan.2.1.1.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossMan.2.1.1.Beta2
>
>
> The ManagedObject.hasDefaultName needs to be set to false when setting a @ManagementObjectID, otherwise the default name will be used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 12:05:57 2009
From: jira-events at lists.jboss.org (Hossein Attar (JIRA))
Date: Tue, 2 Jun 2009 12:05:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <27634648.1243958757871.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470270#action_12470270 ] 

Hossein Attar commented on JBMESSAGING-1631:
--------------------------------------------

(On behalf of Victor)
The test  MDB is attached

> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 12:05:58 2009
From: jira-events at lists.jboss.org (Hossein Attar (JIRA))
Date: Tue, 2 Jun 2009 12:05:58 -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: <8760995.1243958758190.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hossein Attar updated JBMESSAGING-1631:
---------------------------------------

    Attachment: TestRecommendationSentProcessorMDB.java


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 12:10:57 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 2 Jun 2009 12:10:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6983) Error configuring
 property: sessionIdAlphabet for WarDeployer
In-Reply-To: <16967894.1243494296657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14735809.1243959057369.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated JBAS-6983:
-----------------------------------

    Workaround Description: Move the <property name="sessionIdAlphabet">ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+-_</property> configuration element out of war-deployers-jboss-beans.xml and into the <bean name="WebServer"  class="org.jboss.web.tomcat.service.deployers.TomcatService"> bean in deploy/jbossweb.sar/META-INF/jboss-beans.xml.
                Workaround: [Workaround Exists]


Posted a workaround for those who need to configure this. The workaround is a kludge, but it works.

Remy, TBH the clustering code's use of it's own session id generation algorithm predates my involvement so I'm not familiar with the subtleties of why Ben went that way. I'll try and ping him. I know a year or two ago there were reports of session id collisions with the Tomcat algorithm and I never heard of any with the SessionIdGenerator, so I just left well enough alone. :)  I'd prefer though to get rid of SessionIdGenerator if possible.

Manuel, I'm curious as to why you wanted to configure this. If for future releases getting rid of SessionIdGenerator isn't practical, then changing to config via system property is a possibility. That's not as controllable via management tools like embedded console/Jopr/JON, so before doing that I'd like to get a better feel as to why/how often people would want to configure this.

> Error configuring property: sessionIdAlphabet for WarDeployer
> -------------------------------------------------------------
>
>                 Key: JBAS-6983
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6983
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: JBoss 5.0.1.GA or JBoss 5.1.0.GA
>            Reporter: Manuel Aznar Perez
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> At "server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml" when i uncomment "<property name="sessionIdAlphabet">" and run JBoss. Launch exception:
> 2009-05-28 08:34:34,670 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Configured: name=WarDeployer state=Instantiated
> java.lang.RuntimeException: Error configuring property: sessionIdAlphabet for WarDeployer
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112)
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85)
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44)
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
>         at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
>         at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
>         at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> That is because don't have "jboss-web-service.jar" in deployer. 
> This jar is in "deploy/jbossweb.sar".
> This is fixed copy jar file to deployer directory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 12:24:30 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Tue, 2 Jun 2009 12:24:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6942) Expose a
 testConnection operation via JMX
In-Reply-To: <25565782.1242746073015.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27803486.1243959885838.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470274#action_12470274 ] 

Ian Springer commented on JBAS-6942:
------------------------------------

Jesper, which MBean exposes the new operation and what is the name of the operation?

Also, did you expose the functionality via the Profile Service as well, or only JMX?

Thanks,
Ian


> Expose a testConnection operation via JMX
> -----------------------------------------
>
>                 Key: JBAS-6942
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6942
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>            Reporter: Heiko W. Rupp
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Hi, 
> would it be possible to expose a "tesConnection" method to JMX and/or the profile service, that basically tries to get a connection with the backend database and returns true if this was successful. The connection itself could directly be closed or put back into the pool. Obtaining the connection should always try to really hit the database and not just get a connection from the pool (unless the valid connection checking mechanism is used, which may or may not be configured on a datasource).
> Such an operation could be very handy for tools like Jopr. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 12:39:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 2 Jun 2009 12:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6942) Expose a
 testConnection operation via JMX
In-Reply-To: <25565782.1242746073015.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26526483.1243960796711.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470276#action_12470276 ] 

Jesper Pedersen commented on JBAS-6942:
---------------------------------------

Method is on JBossManagedConnectionPoolMBean

 boolean testConnection()

It is exposed through @ManagedOperation also.

> Expose a testConnection operation via JMX
> -----------------------------------------
>
>                 Key: JBAS-6942
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6942
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>            Reporter: Heiko W. Rupp
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Hi, 
> would it be possible to expose a "tesConnection" method to JMX and/or the profile service, that basically tries to get a connection with the backend database and returns true if this was successful. The connection itself could directly be closed or put back into the pool. Obtaining the connection should always try to really hit the database and not just get a connection from the pool (unless the valid connection checking mechanism is used, which may or may not be configured on a datasource).
> Such an operation could be very handy for tools like Jopr. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 13:13:57 2009
From: jira-events at lists.jboss.org (Hossein Attar (JIRA))
Date: Tue, 2 Jun 2009 13:13:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <4014849.1243962837486.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470282#action_12470282 ] 

Hossein Attar commented on JBMESSAGING-1631:
--------------------------------------------

Howard:
I think your test case is right. Here are some details about our environment that may be useful.
We use java:/JmsXA as our connection factory
In hajndi-jms-ds.xml, we have
  <!-- JMS XA Resource adapter, use this to get transacted JMS in beans -->
  <tx-connection-factory>
    <jndi-name>JmsXA</jndi-name>
    <xa-transaction/>
    <rar-name>jms-ra.rar</rar-name>
    <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
    <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
    <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
    <max-pool-size>20</max-pool-size>
    <security-domain-and-application>JmsXARealm</security-domain-and-application>
  </tx-connection-factory>



and in  connection-factories-service.xml, we have 


   <!-- The default connection factory does not support automatic failover or load balancing-
        this is so we can maintain compatiblity with applications written for JBoss MQ which use this
        connection factory.
   -->     
   <mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"
      name="jboss.messaging.connectionfactory:service=ConnectionFactory"
      xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends optional-attribute-name="Connector">jboss.messaging:service=Connector,transport=bisocket</depends>
      <depends>jboss.messaging:service=PostOffice</depends>

      <attribute name="JNDIBindings">
         <bindings>
            <binding>/ConnectionFactory</binding>
            <binding>/XAConnectionFactory</binding>
            <binding>java:/ConnectionFactory</binding>
            <binding>java:/XAConnectionFactory</binding>
         </bindings>
      </attribute>
   </mbean>

   <!-- A clustered connection factory that supports automatic failover and load balancing of created
        connections.
        This factory is not suitable to be used by MDBs.
   -->
   <mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"
      name="jboss.messaging.connectionfactory:service=ClusteredConnectionFactory"
      xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends optional-attribute-name="Connector">jboss.messaging:service=Connector,transport=bisocket</depends>
      <depends>jboss.messaging:service=PostOffice</depends>

      <attribute name="JNDIBindings">
         <bindings>
            <binding>/ClusteredConnectionFactory</binding>
            <binding>/ClusteredXAConnectionFactory</binding>
            <binding>java:/ClusteredConnectionFactory</binding>
            <binding>java:/ClusteredXAConnectionFactory</binding>
         </bindings>
      </attribute>

      <attribute name="SupportsFailover">true</attribute>
      <attribute name="SupportsLoadBalancing">true</attribute>      
   </mbean>
   
   <!-- A connection factory with no JNDI bindings that is used in clustering to create the connections that
        pull messages from one node to another
   -->
   <mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"
      name="jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory"
      xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends optional-attribute-name="Connector">jboss.messaging:service=Connector,transport=bisocket</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
      <attribute name="SupportsFailover">false</attribute>
      <attribute name="SupportsLoadBalancing">false</attribute>      
   </mbean>
   

> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 13:42:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 2 Jun 2009 13:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1637)
	Interruption is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20608493.1243964576510.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470289#action_12470289 ] 

Tim Fox commented on JBMESSAGING-1637:
--------------------------------------

Ok, ok, you win :)

We'll get this done by the next release...

> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>             Fix For: 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 13:55:58 2009
From: jira-events at lists.jboss.org (Marius Bogoevici (JIRA))
Date: Tue, 2 Jun 2009 13:55:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBSPRING-6) Modify the Maven
 build file to create the spring.deployer
In-Reply-To: <9759864.1242189598333.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29791617.1243965358589.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBSPRING-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marius Bogoevici resolved JBSPRING-6.
-------------------------------------

    Resolution: Done


> Modify the Maven build file to create the spring.deployer
> ---------------------------------------------------------
>
>                 Key: JBSPRING-6
>                 URL: https://jira.jboss.org/jira/browse/JBSPRING-6
>             Project: JBoss Spring Integration
>          Issue Type: Feature Request
>            Reporter: Marius Bogoevici
>            Assignee: Marius Bogoevici
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 13:55:59 2009
From: jira-events at lists.jboss.org (Marius Bogoevici (JIRA))
Date: Tue, 2 Jun 2009 13:55:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSPRING-6) Modify the Maven
 build file to create the spring.deployer
In-Reply-To: <9759864.1242189598333.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16524959.1243965359341.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBSPRING-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marius Bogoevici closed JBSPRING-6.
-----------------------------------



> Modify the Maven build file to create the spring.deployer
> ---------------------------------------------------------
>
>                 Key: JBSPRING-6
>                 URL: https://jira.jboss.org/jira/browse/JBSPRING-6
>             Project: JBoss Spring Integration
>          Issue Type: Feature Request
>            Reporter: Marius Bogoevici
>            Assignee: Marius Bogoevici
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 17:47:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 2 Jun 2009 17:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6844) Remove "embedded"
	module
In-Reply-To: <30880585.1241013647667.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7583882.1243979276935.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-6844.
---------------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> Remove "embedded" module
> ------------------------
>
>                 Key: JBAS-6844
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6844
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The "embedded" module is now legacy and should be pulled from the source tree and moved under an embedded-legacy component.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 18:14:56 2009
From: jira-events at lists.jboss.org (Mike Van Noord (JIRA))
Date: Tue, 2 Jun 2009 18:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6996)
 ClassNotFoundException for array types in JDK6
Message-ID: <4729180.1243980896777.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClassNotFoundException for array types in JDK6
----------------------------------------------

                 Key: JBAS-6996
                 URL: https://jira.jboss.org/jira/browse/JBAS-6996
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMX
    Affects Versions: JBossAS-5.1.0.GA
         Environment: JDK 1.6
            Reporter: Mike Van Noord
            Assignee: Dimitris Andreadis


org.jboss.mx.server.InvocationContext uses the ClassLoader.loadClass() call rather than Class.forName().  Due to a behavioral change from Java 5 to Java 6, this call now throws a ClassNotFoundException when that class is of an array type, e.g. "[Ljava.lang.String;".

The situation is the same as the one described here: https://jira.jboss.org/jira/browse/JBRULES-1553

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 20:01:00 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Tue, 2 Jun 2009 20:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-124) Implement SAMLV2.0
	validation
Message-ID: <26312958.1243987260389.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement SAMLV2.0 validation
-----------------------------

                 Key: JBID-124
                 URL: https://jira.jboss.org/jira/browse/JBID-124
             Project: JBoss Identity
          Issue Type: Sub-task
          Components: Identity-Federation
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: IDFED-1.0.0.alpha3


The SAML token provider must be able to validate the assertions it generates. This involves validating the digital signature and also the assertion validity period (lifetime).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 22:54:56 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 2 Jun 2009 22:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-328) support Java
 attributes and elements
In-Reply-To: <26091683.1241701314495.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15548526.1243997696713.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-328.
---------------------------

    Resolution: Done


> support Java attributes and elements
> ------------------------------------
>
>                 Key: GPD-328
>                 URL: https://jira.jboss.org/jira/browse/GPD-328
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.CR1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> attributes: class, method, var
> elements: field, arg

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 23:28:56 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 2 Jun 2009 23:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-345) XML namespaces are
 not consistent between GPD and the engine
In-Reply-To: <25020237.1243434353653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33541158.1243999736885.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-345.
---------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.CR1
       Resolution: Duplicate Issue


duplicate of GPD-338

> XML namespaces are not consistent between GPD and the engine
> ------------------------------------------------------------
>
>                 Key: GPD-345
>                 URL: https://jira.jboss.org/jira/browse/GPD-345
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>         Environment: GPD from jbpm-4.0.0.Beta2
>            Reporter: Alexis Seigneurin
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.CR1
>
>
> The graphical designer and the process engine do not use the same XML namespace. GPD uses http://jbpm.org/4/jpdl whereas the engine uses http://jbpm.org/4.0/jpdl.
> The consequence is that a process created with the designer does not work in the engine. You get errors like these:
> 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: start>
> 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: decision>
> 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: state>
> 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: state>
> 2009-05-27 16:19:09,117 DEBUG [org.jbpm.jpdl.internal.xml.JpdlParser] - <unrecognized activity: state>
> 2009-05-27 16:19:09,258 INFO [org.jbpm.pvm.internal.repository.RepositorySessionImpl] - <errors during deployment of deployment(96): 
>   error: no start activity in process >

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 23:28:57 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 2 Jun 2009 23:28:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-348) jdpl.xml xmlns
	altered wrong
In-Reply-To: <11700206.1243712216785.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8514537.1243999737389.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-348.
---------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.CR1
       Resolution: Duplicate Issue


duplicate of GPD-338

> jdpl.xml xmlns altered wrong
> ----------------------------
>
>                 Key: GPD-348
>                 URL: https://jira.jboss.org/jira/browse/GPD-348
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM jPDL Designer 4.0.0.beta2
>            Reporter: Johan Kumps
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.0.CR1
>
>
> When changing the layout in the diagram view, the xmlns="http://jbpm.org/4.0/jpdl" is altered to xmlns="http://jbpm.org/4/jpdl" causing :
> org.jbpm.api.JbpmException:
>   error: no start activity in process
>         at org.jbpm.pvm.internal.xml.ProblemList.getJbpmException(ProblemList.java:169)
>         at org.jbpm.pvm.internal.xml.ProblemList.getJbpmException(ProblemList.java:142)
>         at org.jbpm.pvm.internal.repository.RepositorySessionImpl.deploy(RepositorySessionImpl.java:58)
>         at org.jbpm.pvm.internal.cmd.DeployCmd.execute(DeployCmd.java:47)
>         at org.jbpm.pvm.internal.cmd.DeployCmd.execute(DeployCmd.java:33)
>         at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
>         at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:54)
>         at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:54)
>         at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
>         at org.jbpm.pvm.internal.repository.DeploymentImpl.deploy(DeploymentImpl.java:81)
>         at org.jbpm.pvm.internal.ant.JbpmDeployTask.deployFile(JbpmDeployTask.java:108)
>         at org.jbpm.pvm.internal.ant.JbpmDeployTask.execute(JbpmDeployTask.java:60)
>         at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
>         at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
>         at org.apache.tools.ant.Task.perform(Task.java:348)
>         at org.apache.tools.ant.Target.execute(Target.java:357)
>         at org.apache.tools.ant.Target.performTasks(Target.java:385)
>         at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
>         at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
>         at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
>         at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
>         at org.apache.tools.ant.Main.runBuild(Main.java:758)
>         at org.apache.tools.ant.Main.startAnt(Main.java:217)
>         at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
>         at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  2 23:31:07 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 2 Jun 2009 23:31:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <26384952.1243999867672.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470332#action_12470332 ] 

Howard Gao commented on JBMESSAGING-1631:
-----------------------------------------

Hi Hossein,

Thanks a lot for the info!

Howard


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 02:31:56 2009
From: jira-events at lists.jboss.org (Manuel Aznar Perez (JIRA))
Date: Wed, 3 Jun 2009 02:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6983) Error configuring
 property: sessionIdAlphabet for WarDeployer
In-Reply-To: <16967894.1243494296657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19094856.1244010716778.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470342#action_12470342 ] 

Manuel Aznar Perez commented on JBAS-6983:
------------------------------------------

A customer needs that.

I need remove character "+" because an old big customer application pass sessionId at the GET parameter, then character "+" == space blank. 

I changed character "+" to "*". Then it works fine.

It's migration Tomcat to JBossWeb. This at Tomcat don't fail.

> Error configuring property: sessionIdAlphabet for WarDeployer
> -------------------------------------------------------------
>
>                 Key: JBAS-6983
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6983
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: JBoss 5.0.1.GA or JBoss 5.1.0.GA
>            Reporter: Manuel Aznar Perez
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> At "server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml" when i uncomment "<property name="sessionIdAlphabet">" and run JBoss. Launch exception:
> 2009-05-28 08:34:34,670 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Configured: name=WarDeployer state=Instantiated
> java.lang.RuntimeException: Error configuring property: sessionIdAlphabet for WarDeployer
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112)
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85)
>         at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44)
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
>         at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
>         at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
>         at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> That is because don't have "jboss-web-service.jar" in deployer. 
> This jar is in "deploy/jbossweb.sar".
> This is fixed copy jar file to deployer directory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 03:50:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 03:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-837) Add failure simulation
 capabilities to Simulator
In-Reply-To: <8863048.1224253881092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26245055.1244015457752.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-837:
--------------------------

    Fix Version/s: 3.x


> Add failure simulation capabilities to Simulator 
> -------------------------------------------------
>
>                 Key: JGRP-837
>                 URL: https://jira.jboss.org/jira/browse/JGRP-837
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>            Priority: Minor
>             Fix For: 3.x
>
>
> The Simulator can be used to test protocol layers in isolation. Multiple Simulator instances can be configured so that they model a multicast group.
> In its present state, messages are transported from one Simulator instance to another by the send_thread, which moves messages from send_queue to recv_queue in a reliable fashion.  Futhermore, all Simulators perform at the same speed. I'd like to use the Simulator to additionally simulate failures, in order to check the robustness of the protocols. In particular, i'd like to model:
> * dropped, reordered, corrupted messages
> * failed processors ('crash' failure)
> * network partitions
> * slow processes
> This JIRA issue will track progress on this and allow for discussion.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 03:50:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 03:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-912) Failed to parse the
 jgroups.xml file
In-Reply-To: <13018129.1235533725240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6604282.1244015457601.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-912:
--------------------------

    Fix Version/s: 2.6.11
                   2.8


> Failed to parse the jgroups.xml file
> ------------------------------------
>
>                 Key: JGRP-912
>                 URL: https://jira.jboss.org/jira/browse/JGRP-912
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.8
>         Environment: jdk 6, jboss cache 3.0.2 GA, jgroup 2.6.8, wind0ws XP
>            Reporter: sridhar reddy
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: GridJbossCacheManager.java, jboss-cache.xml, jgroups.xml
>
>
> I have the following jboss cache xml as below
> [code]
> <?xml version="1.0" encoding="UTF-8"?>
> <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:jboss:jbosscache-core:config:3.0">
> <locking isolationLevel="READ_COMMITTED"
> lockParentForChildInsertRemove="false" lockAcquisitionTimeout="20000"
> nodeLockingScheme="mvcc" writeSkewCheck="false"
> concurrencyLevel="500" />
> <transaction
> transactionManagerLookupClass="org.jboss.cache.transaction.GenericTransactionManagerLookup"
> syncRollbackPhase="false" syncCommitPhase="false" />
> <eviction wakeUpInterval="500">
> <default algorithmClass="org.jboss.cache.eviction.LRUAlgorithm"
> eventQueueSize="200000">
> <property name="maxNodes" value="5000" />
> <property name="timeToLive" value="1000" />
> </default>
> <region name="/org/jboss/data1">
> <property name="timeToLive" value="2000" />
> </region>
> <region name="/org/jboss/data2"
> algorithmClass="org.jboss.cache.eviction.FIFOAlgorithm"
> eventQueueSize="100000">
> <property name="maxNodes" value="3000" />
> <property name="minTimeToLive" value="4000" />
> </region>
> </eviction>
> <clustering mode="replication" >
> <jgroupsConfig configFile="C:/workspace/GridJBCache3/src/config/jgroups.xml" />
> </clustering>
> <loaders passivation="false" shared="false">
> <preload>
> <node fqn="/" />
> </preload>
> <loader class="org.jboss.cache.loader.JDBCCacheLoader"
> async="true" fetchPersistentState="true" ignoreModifications="true"
> purgeOnStartup="true">
> <properties>
> cache.jdbc.table.name=jbosscache
> cache.jdbc.table.create=true
> cache.jdbc.table.drop=false
> cache.jdbc.table.primarykey=jbosscache_pk
> cache.jdbc.fqn.column=fqn
> cache.jdbc.fqn.type=varchar(255)
> cache.jdbc.node.column=node
> cache.jdbc.node.type=bytea
> cache.jdbc.parent.column=parent
> cache.jdbc.driver=org.postgresql.Driver
> cache.jdbc.url=jdbc:postgresql://localhost:5432/facts7
> cache.jdbc.user=f7tms
> cache.jdbc.password=f7tms
> </properties>
> </loader>
> </loaders>
> </jbosscache>
> [/code]
> and jgroups.xml file as below
> [code]
> <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="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="discard"
> oob_thread_pool.enabled="true" oob_thread_pool.min_threads="1"
> oob_thread_pool.max_threads="8"
> oob_thread_pool.keep_alive_time="5000"
> oob_thread_pool.queue_enabled="false"
> oob_thread_pool.queue_max_size="100"
> oob_thread_pool.rejection_policy="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="3000"
> 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 /
> -->
> </config>
> [/code]
> My code start the cache as
> [code]
> package org.gridgain.examples.jbosscache;
> import java.io.File;
> import org.jboss.cache.Cache;
> import org.jboss.cache.CacheFactory;
> import org.jboss.cache.DefaultCacheFactory;
> import org.jboss.cache.Fqn;
> import org.jboss.cache.Node;
> import org.jboss.cache.config.Configuration;
> import org.jboss.cache.config.parsing.XmlConfigurationParser;
> import org.jgroups.JChannelFactory;
> public final class GridJbossCacheManager {
>     /** Cache configuration path relative to GridGain installation. */
>     public static final String CACHE_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jboss-cache.xml";
>     /** JGroups configuration path relative to GridGain installation. */
>     public static final String JGROUPS_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jgroups.xml";
>     /** JBoss Cache instance. */
>     private Cache<Long, String> cache = null;
>     /** Cache node for caching example data. */
>     private Node<Long, String> cacheRoot = null;
>     /** Singleton instance. */
>     private static GridJbossCacheManager instance = new GridJbossCacheManager();
>     /**
>      * Gets singleton.
>      *
>      * @return Singleton.
>      */
>     public static GridJbossCacheManager getInstance() {
>         return instance;
>     }
>     /**
>      * Ensure singleton.
>      */
>     private GridJbossCacheManager() {
>         // No-op.
>     }
>    
>     public void start() throws GridException {
>         File cacheCfg = new File(CACHE_CFG_PATH);
>         if (cacheCfg == null) {
>             throw new GridException("Failed to find cache configuration file: " + CACHE_CFG_PATH);
>         }
>         File jgroupsCfg = new File(JGROUPS_CFG_PATH);
>         if (jgroupsCfg == null) {
>             throw new GridException("Failed to find jgroups configuration: " + JGROUPS_CFG_PATH);
>         }
>         // Make sure JBoss Cache and GridGain are on the same "wave length".
>         JChannelFactory factory = new JChannelFactory(); //null;
>         try {
>          //factory = new JChannelFactory(jgroupsCfg);
>             factory.setMultiplexerConfig(jgroupsCfg.getCanonicalPath());
>         }
>         catch (Exception e) {
>             throw new GridException("Failed to start Data Manager.", e);
>         }
>         try {
>             XmlConfigurationParser parser = new XmlConfigurationParser();
>             // Start JBoss Cache cache with shared JGroups configuration.
>             Configuration svrCfg = parser.parseFile(cacheCfg.getCanonicalPath());
>             svrCfg.getRuntimeConfig().setMuxChannelFactory(factory);
>             CacheFactory<Long, String> dataFactory = DefaultCacheFactory.getInstance();
>             // Instantiate and start JBoss Cache.
>             cache = dataFactory.createCache(svrCfg);
>             // Cache node for storing example data.
>             cacheRoot = cache.getRoot().addChild(Fqn.fromString("/"));
>         }
>         catch (Exception e) {
>             throw new GridException("Failed to start Data Manager.", e);
>         }
>         System.out.println("JBoss Cache data manager started.");
>     }
>    
> }
> [/code]
> When i ran this program i am getting the following error
> [code]
> Exception in thread "main"
> Exception:
> ----------
> >>> Type: java.lang.Exception
> >>> Message: failed parsing C:\workspace\GridJBCache3\src\config\jgroups.xml
> >>> Stack trace:
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:216)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> Caused By:
> ----------
> >>> Type: java.io.IOException
> >>> Message: invalid XML configuration: XML protocol stack configuration does not start with a '<config>' element; maybe the XML configuration needs to be converted to the new format ?
> use 'java org.jgroups.conf.XmlConfigurator <old XML file> -new_format' to do so
> >>> Stack trace:
> >>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:476)
> >>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:462)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:213)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> [/code]
> Now i have added the
> [code]
> <protocol_stacks>
> <stack name="udp"
> description="Default: IP multicast based stack, with flow control and message bundling">
> [/code]
> to jgroups.xml. When i ran the program, its giving the following error.
> [code]
> log4j:WARN No appenders could be found for logger (org.jboss.cache.util.FileLookup).
> log4j:WARN Please initialize the log4j system properly.
> Exception in thread "main" org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
> at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:148)
> at org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(ComponentRegistry.java:1005)
> at org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegistry.java:775)
> at org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java:629)
> at org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocationDelegate.java:344)
> at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:121)
> at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:105)
> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:148)
> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:144)
> ... 9 more
> Caused by: org.jboss.cache.CacheException: Failed to create multiplexed channel using stack null
> at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:353)
> at org.jboss.cache.RPCManagerImpl.initialiseChannelAndRpcDispatcher(RPCManagerImpl.java:267)
> at org.jboss.cache.RPCManagerImpl.start(RPCManagerImpl.java:167)
> ... 14 more
> Caused by: java.lang.IllegalArgumentException: stack name and service ID have to be non null
> at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:336)
> at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:328)
> at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:349)
> ... 16 more
> [/code] 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 03:59:56 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Wed, 3 Jun 2009 03:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-88)
 ProfileServiceBootstrap: Failed to build ManagedDeployment
In-Reply-To: <10128448.1244015996530.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30283758.1244015996712.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Medek updated JBBOOT-88:
-------------------------------

    Attachment: boot.log


> ProfileServiceBootstrap: Failed to build ManagedDeployment
> ----------------------------------------------------------
>
>                 Key: JBBOOT-88
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-88
>             Project: JBoss Bootstrap
>          Issue Type: Bug
>         Environment: JBoss AS 5.1.0, WinXP, jdk 1.6.0u13
>            Reporter: Ondrej Medek
>            Assignee: Andrew Lee Rubinger
>         Attachments: boot.log
>
>
> I see two exception in my boot.log: DEBUG [ProfileServiceBootstrap] Failed to build ManagedDeployment for:
> 1) AbstractKernelDeployment at 1cd427a{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml installed=true beanFactories=[AbstractBeanMetaData at c791f4{name=VFSCache bean=null properties=[realCache, permanentRoots] constructor=AbstractConstructorMetaData at 198defc{parameters=[null] factoryClass=org.jboss.virtual.spi.cache.VFSCacheFactory factoryMethod=getInstance} autowireCandidate=true start=AbstractLifecycleMetaData at 1579a30{ whenRequired=ControllerState at 3f58bb{Start} parameters= }}, AbstractBeanMetaData at da9067{name=VfsNamesExceptionHandler bean=org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler properties= constructor=AbstractConstructorMetaData at 13e9934{parameters=[java.lang.String]} autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 2) AbstractKernelDeployment at 17044c5{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml installed=true beanFactories=[AbstractBeanMetaData at 1b2e44d{name=LogBridgeHandler bean=org.jboss.logbridge.LogBridgeHandler properties= constructor=null autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 03:59:56 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Wed, 3 Jun 2009 03:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-88)
 ProfileServiceBootstrap: Failed to build ManagedDeployment
Message-ID: <10128448.1244015996530.JavaMail.jira@cloud.prod.atl2.jboss.com>

ProfileServiceBootstrap: Failed to build ManagedDeployment
----------------------------------------------------------

                 Key: JBBOOT-88
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-88
             Project: JBoss Bootstrap
          Issue Type: Bug
         Environment: JBoss AS 5.1.0, WinXP, jdk 1.6.0u13
            Reporter: Ondrej Medek
            Assignee: Andrew Lee Rubinger
         Attachments: boot.log

I see two exception in my boot.log: DEBUG [ProfileServiceBootstrap] Failed to build ManagedDeployment for:

1) AbstractKernelDeployment at 1cd427a{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml installed=true beanFactories=[AbstractBeanMetaData at c791f4{name=VFSCache bean=null properties=[realCache, permanentRoots] constructor=AbstractConstructorMetaData at 198defc{parameters=[null] factoryClass=org.jboss.virtual.spi.cache.VFSCacheFactory factoryMethod=getInstance} autowireCandidate=true start=AbstractLifecycleMetaData at 1579a30{ whenRequired=ControllerState at 3f58bb{Start} parameters= }}, AbstractBeanMetaData at da9067{name=VfsNamesExceptionHandler bean=org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler properties= constructor=AbstractConstructorMetaData at 13e9934{parameters=[java.lang.String]} autowireCandidate=true}]}
org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)


2) AbstractKernelDeployment at 17044c5{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml installed=true beanFactories=[AbstractBeanMetaData at 1b2e44d{name=LogBridgeHandler bean=org.jboss.logbridge.LogBridgeHandler properties= constructor=null autowireCandidate=true}]}
org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 04:20:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 04:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-984) JGroups can not
 parse IPV6 literals in TCPPING protocol configuration
In-Reply-To: <7188979.1242741125294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33004478.1244017256805.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470352#action_12470352 ] 

Bela Ban commented on JGRP-984:
-------------------------------

This works for me, I tried it under 2.4 head. Note that [::1][7810] is *NOT* a valid address, the angle brackets need to be removed ! ::1[7810] works.

Please attach instructions on how to reproduce this, and re-open the case if the problem persists.

> JGroups can not parse IPV6 literals in TCPPING protocol configuration
> ---------------------------------------------------------------------
>
>                 Key: JGRP-984
>                 URL: https://jira.jboss.org/jira/browse/JGRP-984
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.6
>            Reporter: Brian Stansberry
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> ON JBPAPP-2013 Dominik Pospisil reports the IPv6 address parsing fix in 2.4.6 doesn't handle TCPPING:
> Both
> <TCPPING initial_hosts="::1[7810],fec0::f101:21a:a0ff:fea0:d745[7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> and
> <TCPPING initial_hosts="[::1][7810],[fec0::f101:21a:a0ff:fea0:d745][7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> fails with:
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "::1"
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "fec0::f101:21a:a0ff:fea0:d745"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 04:24:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 04:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33340540.1244017496545.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470353#action_12470353 ] 

Bela Ban commented on JGRP-978:
-------------------------------

The problem is that I don't know if JGroups runs in an IPv6-only environment, and we have to pick an address.

The workaround of course is to set the diagnostics address to an IPv6 multicast address, or to disable probing altogether.

Richard: do you know of multicast addresses which are valid for both IPv4 and IPv6 ? And why isn't an IPv4 multicast address automatically converted to an IPv6 address in an IPv6-only environment ?

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 04:40:57 2009
From: jira-events at lists.jboss.org (Victor Starenky (JIRA))
Date: Wed, 3 Jun 2009 04:40:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <21042994.1244018457345.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470355#action_12470355 ] 

Victor Starenky commented on JBMESSAGING-1631:
----------------------------------------------

I think one important thing to reproduce the problem is to cause client/server failover due to timeouts. This could happen either because of unreliable network or due to high cpu usage / lack of resources. If both servers are pretty much idle and sit on a good network it's quite unlikely we'll see the problem.

Another difference between your test case and our environment is that we\re sending messages to the queue from the same application farmed across both servers. We're using both stateless EJB beans to get the XA clustered factory injected by the container for sending messages and just a jndi lookup. I don't think all of this matters as the problems seem to be on a receiving side but still thought I would mention this. 

> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 05:00:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 3 Jun 2009 05:00:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <2193375.1244019657196.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470359#action_12470359 ] 

Howard Gao commented on JBMESSAGING-1631:
-----------------------------------------

Thanks Victor. One thing I can do to trigger failover is reduce the ping timeout in remoting configuration, that worked well in my dealing with JBMESSAGING-1456.



> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 05:07:56 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 3 Jun 2009 05:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-986) FLUSH: relax event
 sequencing for a joining member
In-Reply-To: <16765612.1244019962699.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13754192.1244020076890.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic updated JGRP-986:
-------------------------------------

    Description: 
There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a switch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This switch was introduced to always enforce a strict order between view, unblock and message M. 

If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.

  was:
There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a latch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If a message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This latch was introduced to always enforce a strict order between view, unblock and message M. 

If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.



> FLUSH: relax event sequencing for a joining member
> --------------------------------------------------
>
>                 Key: JGRP-986
>                 URL: https://jira.jboss.org/jira/browse/JGRP-986
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.10, 2.8
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>
> There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a switch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This switch was introduced to always enforce a strict order between view, unblock and message M. 
> If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 05:06:02 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 3 Jun 2009 05:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-986) FLUSH: relax event
 sequencing for a joining member
Message-ID: <16765612.1244019962699.JavaMail.jira@cloud.prod.atl2.jboss.com>

FLUSH: relax event sequencing for a joining member
--------------------------------------------------

                 Key: JGRP-986
                 URL: https://jira.jboss.org/jira/browse/JGRP-986
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.6.10, 2.8
            Reporter: Vladimir Blagojevic
            Assignee: Vladimir Blagojevic
             Fix For: 2.6.11, 2.8


There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a latch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If a message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This latch was introduced to always enforce a strict order between view, unblock and message M. 

If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 05:13:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 05:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-964) shared_transport
 concurrency
 failure - starting NotificationBusses at the same time causes "timer cannot
 be retrieved from protocol stack"
In-Reply-To: <3477014.1240858726835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28791810.1244020436777.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-964.
---------------------------

    Resolution: Done


Fixed by wrapping JChannel.init() with a class-wide lock. This has no impact on regular startup

> shared_transport concurrency failure - starting NotificationBusses at the same time causes "timer cannot be retrieved from protocol stack"
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-964
>                 URL: https://jira.jboss.org/jira/browse/JGRP-964
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Win2000, JVM = JRockit 6, although reproducible with test app under Windows XP and Java 6u13.
>            Reporter: Edward Kuns
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: CoordinationBus.xml, JGroupsTest.java, JGroupsTest.java, log4j.xml
>
>
> I have an application that starts four jgroups NotificationBus's that all share the same UDP transport (with          singleton_name="...") but are otherwise distinct.  Recently, the application started to fail to start with the following stack signature:
> 2009-04-27 13:56:50,425 -0500 ERROR [JGroupsTest] - Exception running bus
> org.jgroups.ChannelException: unable to setup the protocol stack: timer cannot be retrieved from protocol stack
> 	at org.jgroups.JChannel.init(JChannel.java:1574)
> 	at org.jgroups.JChannel.<init>(JChannel.java:257)
> 	at org.jgroups.JChannel.<init>(JChannel.java:240)
> 	at org.jgroups.blocks.NotificationBus.<init>(NotificationBus.java:69)
> 	at JGroupsTest$1.run(JGroupsTest.java:25)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: timer cannot be retrieved from protocol stack
> 	at org.jgroups.protocols.Discovery.init(Discovery.java:98)
> 	at org.jgroups.protocols.PING.init(PING.java:84)
> 	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:641)
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:468)
> 	at org.jgroups.JChannel.init(JChannel.java:1570)
> 	... 5 more
> I created a test application that does nothing but start these four busses, and if I start them simultaneously, I can always reproduce the above error.  I will attach the test application.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 05:15:58 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 3 Jun 2009 05:15:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-912) Failed to parse the
 jgroups.xml file
In-Reply-To: <13018129.1235533725240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23484090.1244020558549.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470367#action_12470367 ] 

Vladimir Blagojevic commented on JGRP-912:
------------------------------------------

Something does not seem right about this snippet here. Please check how you comment elements and use XML editor to verify xml document is well formed!

<FRAG2 frag_size="60000" />
-
<!-- pbcast.STREAMING_STATE_TRANSFER /
-->
<pbcast.STATE_TRANSFER />
-
<!-- pbcast.FLUSH /
--> 

> Failed to parse the jgroups.xml file
> ------------------------------------
>
>                 Key: JGRP-912
>                 URL: https://jira.jboss.org/jira/browse/JGRP-912
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.8
>         Environment: jdk 6, jboss cache 3.0.2 GA, jgroup 2.6.8, wind0ws XP
>            Reporter: sridhar reddy
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: GridJbossCacheManager.java, jboss-cache.xml, jgroups.xml
>
>
> I have the following jboss cache xml as below
> [code]
> <?xml version="1.0" encoding="UTF-8"?>
> <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:jboss:jbosscache-core:config:3.0">
> <locking isolationLevel="READ_COMMITTED"
> lockParentForChildInsertRemove="false" lockAcquisitionTimeout="20000"
> nodeLockingScheme="mvcc" writeSkewCheck="false"
> concurrencyLevel="500" />
> <transaction
> transactionManagerLookupClass="org.jboss.cache.transaction.GenericTransactionManagerLookup"
> syncRollbackPhase="false" syncCommitPhase="false" />
> <eviction wakeUpInterval="500">
> <default algorithmClass="org.jboss.cache.eviction.LRUAlgorithm"
> eventQueueSize="200000">
> <property name="maxNodes" value="5000" />
> <property name="timeToLive" value="1000" />
> </default>
> <region name="/org/jboss/data1">
> <property name="timeToLive" value="2000" />
> </region>
> <region name="/org/jboss/data2"
> algorithmClass="org.jboss.cache.eviction.FIFOAlgorithm"
> eventQueueSize="100000">
> <property name="maxNodes" value="3000" />
> <property name="minTimeToLive" value="4000" />
> </region>
> </eviction>
> <clustering mode="replication" >
> <jgroupsConfig configFile="C:/workspace/GridJBCache3/src/config/jgroups.xml" />
> </clustering>
> <loaders passivation="false" shared="false">
> <preload>
> <node fqn="/" />
> </preload>
> <loader class="org.jboss.cache.loader.JDBCCacheLoader"
> async="true" fetchPersistentState="true" ignoreModifications="true"
> purgeOnStartup="true">
> <properties>
> cache.jdbc.table.name=jbosscache
> cache.jdbc.table.create=true
> cache.jdbc.table.drop=false
> cache.jdbc.table.primarykey=jbosscache_pk
> cache.jdbc.fqn.column=fqn
> cache.jdbc.fqn.type=varchar(255)
> cache.jdbc.node.column=node
> cache.jdbc.node.type=bytea
> cache.jdbc.parent.column=parent
> cache.jdbc.driver=org.postgresql.Driver
> cache.jdbc.url=jdbc:postgresql://localhost:5432/facts7
> cache.jdbc.user=f7tms
> cache.jdbc.password=f7tms
> </properties>
> </loader>
> </loaders>
> </jbosscache>
> [/code]
> and jgroups.xml file as below
> [code]
> <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="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="discard"
> oob_thread_pool.enabled="true" oob_thread_pool.min_threads="1"
> oob_thread_pool.max_threads="8"
> oob_thread_pool.keep_alive_time="5000"
> oob_thread_pool.queue_enabled="false"
> oob_thread_pool.queue_max_size="100"
> oob_thread_pool.rejection_policy="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="3000"
> 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 /
> -->
> </config>
> [/code]
> My code start the cache as
> [code]
> package org.gridgain.examples.jbosscache;
> import java.io.File;
> import org.jboss.cache.Cache;
> import org.jboss.cache.CacheFactory;
> import org.jboss.cache.DefaultCacheFactory;
> import org.jboss.cache.Fqn;
> import org.jboss.cache.Node;
> import org.jboss.cache.config.Configuration;
> import org.jboss.cache.config.parsing.XmlConfigurationParser;
> import org.jgroups.JChannelFactory;
> public final class GridJbossCacheManager {
>     /** Cache configuration path relative to GridGain installation. */
>     public static final String CACHE_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jboss-cache.xml";
>     /** JGroups configuration path relative to GridGain installation. */
>     public static final String JGROUPS_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jgroups.xml";
>     /** JBoss Cache instance. */
>     private Cache<Long, String> cache = null;
>     /** Cache node for caching example data. */
>     private Node<Long, String> cacheRoot = null;
>     /** Singleton instance. */
>     private static GridJbossCacheManager instance = new GridJbossCacheManager();
>     /**
>      * Gets singleton.
>      *
>      * @return Singleton.
>      */
>     public static GridJbossCacheManager getInstance() {
>         return instance;
>     }
>     /**
>      * Ensure singleton.
>      */
>     private GridJbossCacheManager() {
>         // No-op.
>     }
>    
>     public void start() throws GridException {
>         File cacheCfg = new File(CACHE_CFG_PATH);
>         if (cacheCfg == null) {
>             throw new GridException("Failed to find cache configuration file: " + CACHE_CFG_PATH);
>         }
>         File jgroupsCfg = new File(JGROUPS_CFG_PATH);
>         if (jgroupsCfg == null) {
>             throw new GridException("Failed to find jgroups configuration: " + JGROUPS_CFG_PATH);
>         }
>         // Make sure JBoss Cache and GridGain are on the same "wave length".
>         JChannelFactory factory = new JChannelFactory(); //null;
>         try {
>          //factory = new JChannelFactory(jgroupsCfg);
>             factory.setMultiplexerConfig(jgroupsCfg.getCanonicalPath());
>         }
>         catch (Exception e) {
>             throw new GridException("Failed to start Data Manager.", e);
>         }
>         try {
>             XmlConfigurationParser parser = new XmlConfigurationParser();
>             // Start JBoss Cache cache with shared JGroups configuration.
>             Configuration svrCfg = parser.parseFile(cacheCfg.getCanonicalPath());
>             svrCfg.getRuntimeConfig().setMuxChannelFactory(factory);
>             CacheFactory<Long, String> dataFactory = DefaultCacheFactory.getInstance();
>             // Instantiate and start JBoss Cache.
>             cache = dataFactory.createCache(svrCfg);
>             // Cache node for storing example data.
>             cacheRoot = cache.getRoot().addChild(Fqn.fromString("/"));
>         }
>         catch (Exception e) {
>             throw new GridException("Failed to start Data Manager.", e);
>         }
>         System.out.println("JBoss Cache data manager started.");
>     }
>    
> }
> [/code]
> When i ran this program i am getting the following error
> [code]
> Exception in thread "main"
> Exception:
> ----------
> >>> Type: java.lang.Exception
> >>> Message: failed parsing C:\workspace\GridJBCache3\src\config\jgroups.xml
> >>> Stack trace:
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:216)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> Caused By:
> ----------
> >>> Type: java.io.IOException
> >>> Message: invalid XML configuration: XML protocol stack configuration does not start with a '<config>' element; maybe the XML configuration needs to be converted to the new format ?
> use 'java org.jgroups.conf.XmlConfigurator <old XML file> -new_format' to do so
> >>> Stack trace:
> >>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:476)
> >>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:462)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:213)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> [/code]
> Now i have added the
> [code]
> <protocol_stacks>
> <stack name="udp"
> description="Default: IP multicast based stack, with flow control and message bundling">
> [/code]
> to jgroups.xml. When i ran the program, its giving the following error.
> [code]
> log4j:WARN No appenders could be found for logger (org.jboss.cache.util.FileLookup).
> log4j:WARN Please initialize the log4j system properly.
> Exception in thread "main" org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
> at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:148)
> at org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(ComponentRegistry.java:1005)
> at org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegistry.java:775)
> at org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java:629)
> at org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocationDelegate.java:344)
> at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:121)
> at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:105)
> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:148)
> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:144)
> ... 9 more
> Caused by: org.jboss.cache.CacheException: Failed to create multiplexed channel using stack null
> at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:353)
> at org.jboss.cache.RPCManagerImpl.initialiseChannelAndRpcDispatcher(RPCManagerImpl.java:267)
> at org.jboss.cache.RPCManagerImpl.start(RPCManagerImpl.java:167)
> ... 14 more
> Caused by: java.lang.IllegalArgumentException: stack name and service ID have to be non null
> at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:336)
> at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:328)
> at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:349)
> ... 16 more
> [/code] 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 05:43:07 2009
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Wed, 3 Jun 2009 05:43:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2406) Chapter 3.4
 'Configuring the
 Email Service' incorrectly references CMS workflow notifications
Message-ID: <7844852.1244022187159.JavaMail.jira@cloud.prod.atl2.jboss.com>

Chapter 3.4 'Configuring the Email Service' incorrectly references CMS workflow notifications
---------------------------------------------------------------------------------------------

                 Key: JBPORTAL-2406
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2406
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Reference Guide
    Affects Versions: 2.7.1 Final, 2.6.7 Final
            Reporter: Martin Putz


The first paragraph in Chapter 3.4 'Configuring the Email Service' incorrectly references CMS workflow notifications:

"The email service, for example, can be used to verify a user's email address when a user subscribes, or for CMS workflow notifications."

The CMS approval workflow is now based upon GUI operations instead of email notifications. Therefore, the last part of the sentence above is misleading and should be removed. The same applies to the EPP docs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 06:04:00 2009
From: jira-events at lists.jboss.org (Andrzej Smolinski (JIRA))
Date: Wed, 3 Jun 2009 06:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1650) Need
 EL-replacement within
 @RemoteBinding.clientBindUrl so connect addresses are not hardcoded
In-Reply-To: <13986808.1229942454491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25032118.1244023440776.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470371#action_12470371 ] 

Andrzej Smolinski commented on EJBTHREE-1650:
---------------------------------------------

Is there any workaround? If not when it is planned to be resolved?

> Need EL-replacement within @RemoteBinding.clientBindUrl so connect addresses are not hardcoded
> ----------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1650
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1650
>             Project: EJB 3.0
>          Issue Type: Feature Request
>         Environment: CentOS release 5 (Final)
>            Reporter: amar slimane
>            Assignee: Andrew Lee Rubinger
>
> With JBoss5.0.0.Beta4, it's possible to specify 'jboss.bind.address' as a remoting binding with setting 'clientBindUrl' to 0.0.0.0  :
> @RemoteBindings({
>   @RemoteBinding( clientBindUrl="socket://3873:",       jndiBinding = "jndiBind1") ,
>   @RemoteBinding( clientBindUrl="sslsocket://3843:",  jndiBinding = "jndiBind2") ,
>   @RemoteBinding( clientBindUrl="https://0.0.0.0:8443/servlet-invoker/SSLServerInvokerServlet",  jndiBinding = "jndiBind3") ,
> })
> This don't work with JBoss5.0.0.GA and  it's impossible to have multiple remoting binds  for an EJB.
> It's critical for our application and we don't know if there is a workaround.
> This issue is  probably relative to https://jira.jboss.org/jira/browse/EJBTHREE-1610

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 06:25:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 3 Jun 2009 06:25:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12442811.1244024756537.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470376#action_12470376 ] 

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

On a given host, we can have three possible cases of coexistence between IPv4 and IPv6: IPv4 only support, IPv6 only support or dual-stack IPv4 and IPv6 support. I have read informally that dual-stack support is not available on certain OSs (e.g. Windows XP, Windows 2003, OpenBSD)

On dual stack machines, IPv6 has some special features for supporting the transition from IPv4 to IPv6. One of these is IPv4-mapped addresses, where an IPv4 address can be used together with the IPv6 API. This allows IPv4 clients to talk to IPv6 servers, for example. It also allows managing IPv4 clients and servers from an IPv6 interface. The IPv6 API is used at the transport level (e.g. TCP, UDP) when opening a socket. At the network level, however, the packets are shipped using IPv4.  

I don't know of (and I suspect there is not) a multicast address which is valid for both IPv4 and IPv6. 
Why isn't an IPv4 multicast address converted automatically to an IPv6 address in an IPv6-only environment? Possibly because multicast in IPv6 is scoped and so it would be difficult to know which scope to use for a given IPv4 multicast address.

I guess this is mainly an issue of making all the defaults for IP addresses configurable, so the user has at least the option of implementing the workaround. It may be just a lot of unnecessary and error prone work to try to have JGroups detect the particular case of coexistence between IPv4 and IPv6 that it happens to be in.

  

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 07:19:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 3 Jun 2009 07:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6997) Log a message on the
 console when
 the Log4jService scheduled task picks up changes to jboss-log4j
 configuration
Message-ID: <10819216.1244027996481.JavaMail.jira@cloud.prod.atl2.jboss.com>

Log a message on the console when the Log4jService scheduled task picks up changes to jboss-log4j configuration
---------------------------------------------------------------------------------------------------------------

                 Key: JBAS-6997
                 URL: https://jira.jboss.org/jira/browse/JBAS-6997
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Logging
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: jaikiran pai
            Assignee: jaikiran pai
            Priority: Minor
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


AS-4.x used to log a message to the console to indicate that any dynamic changes to the jboss-log4j.xml have been picked up. This message is now logged at DEBUG level and hence does not (by default) appear on console. Logging this at INFO level would help users to see a confirmation that their changes to jboss-log4j.xml have been picked up dynamically.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 07:21:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 3 Jun 2009 07:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6997) Log a message on the
 console when
 the Log4jService scheduled task picks up changes to jboss-log4j.xml
 configuration
In-Reply-To: <10819216.1244027996481.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7583082.1244028116599.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated JBAS-6997:
-------------------------------

    Summary: Log a message on the console when the Log4jService scheduled task picks up changes to jboss-log4j.xml configuration  (was: Log a message on the console when the Log4jService scheduled task picks up changes to jboss-log4j configuration)


> Log a message on the console when the Log4jService scheduled task picks up changes to jboss-log4j.xml configuration
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6997
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6997
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> AS-4.x used to log a message to the console to indicate that any dynamic changes to the jboss-log4j.xml have been picked up. This message is now logged at DEBUG level and hence does not (by default) appear on console. Logging this at INFO level would help users to see a confirmation that their changes to jboss-log4j.xml have been picked up dynamically.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:17:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 3 Jun 2009 08:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6997) Log a message on
 the console
 when the Log4jService scheduled task picks up changes to jboss-log4j.xml
 configuration
In-Reply-To: <10819216.1244027996481.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9484142.1244031476467.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-6997.
--------------------------------

    Resolution: Done


Similar to JBoss AS-4.x, upon reconfiguration, a INFO level message will be logged:

16:33:42,840 INFO  [Log4jService$URLWatchTimerTask] Configuring from URL: resource:jboss-log4j.xml

> Log a message on the console when the Log4jService scheduled task picks up changes to jboss-log4j.xml configuration
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6997
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6997
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> AS-4.x used to log a message to the console to indicate that any dynamic changes to the jboss-log4j.xml have been picked up. This message is now logged at DEBUG level and hence does not (by default) appear on console. Logging this at INFO level would help users to see a confirmation that their changes to jboss-log4j.xml have been picked up dynamically.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:32:10 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 08:32:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10382056.1244032332314.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470390#action_12470390 ] 

Bela Ban commented on JGRP-978:
-------------------------------

Thanks for the clarification. Since the diagnostics address is configurable, should we close this issue ?

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:32:13 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 3 Jun 2009 08:32:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBID-124) Implement WS-T SAML
 Token Profile:: SAMLV2.0 validation
In-Reply-To: <26312958.1243987260389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6825958.1244032333079.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBID-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470391#action_12470391 ] 

Anil Saldhana commented on JBID-124:
------------------------------------

XMLSignatureUtil and there is XMLTimeUtil for assertion validity checking.

Maybe we need an utility for assertion alone: such as checking if the validity exists etc. (I will add it today).
AssertionExpiredException is the exception.

> Implement WS-T SAML Token Profile:: SAMLV2.0 validation
> -------------------------------------------------------
>
>                 Key: JBID-124
>                 URL: https://jira.jboss.org/jira/browse/JBID-124
>             Project: JBoss Identity
>          Issue Type: Sub-task
>          Components: Identity-Federation
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha3
>
>
> The SAML token provider must be able to validate the assertions it generates. This involves validating the digital signature and also the assertion validity period (lifetime).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:32:05 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 3 Jun 2009 08:32:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-124) Implement WS-T SAML
 Token Profile:: SAMLV2.0 validation
In-Reply-To: <26312958.1243987260389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9309802.1244032325218.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-124:
-------------------------------

    Summary: Implement WS-T SAML Token Profile:: SAMLV2.0 validation  (was: Implement SAMLV2.0 validation)


> Implement WS-T SAML Token Profile:: SAMLV2.0 validation
> -------------------------------------------------------
>
>                 Key: JBID-124
>                 URL: https://jira.jboss.org/jira/browse/JBID-124
>             Project: JBoss Identity
>          Issue Type: Sub-task
>          Components: Identity-Federation
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha3
>
>
> The SAML token provider must be able to validate the assertions it generates. This involves validating the digital signature and also the assertion validity period (lifetime).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:42:19 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 3 Jun 2009 08:42:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-125) AssertionUtil
Message-ID: <27295921.1244032939265.JavaMail.jira@cloud.prod.atl2.jboss.com>

AssertionUtil
-------------

                 Key: JBID-125
                 URL: https://jira.jboss.org/jira/browse/JBID-125
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.alpha3


Utility to deal with assertions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:42:28 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 08:42:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-912) Failed to parse the
 jgroups.xml file
In-Reply-To: <13018129.1235533725240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26584708.1244032948761.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban closed JGRP-912.
-------------------------

    Resolution: Rejected


This is a JBossCache issue, not a JGroups issue ! Please submit to the JBC JIRA

> Failed to parse the jgroups.xml file
> ------------------------------------
>
>                 Key: JGRP-912
>                 URL: https://jira.jboss.org/jira/browse/JGRP-912
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.8
>         Environment: jdk 6, jboss cache 3.0.2 GA, jgroup 2.6.8, wind0ws XP
>            Reporter: sridhar reddy
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: GridJbossCacheManager.java, jboss-cache.xml, jgroups.xml
>
>
> I have the following jboss cache xml as below
> [code]
> <?xml version="1.0" encoding="UTF-8"?>
> <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:jboss:jbosscache-core:config:3.0">
> <locking isolationLevel="READ_COMMITTED"
> lockParentForChildInsertRemove="false" lockAcquisitionTimeout="20000"
> nodeLockingScheme="mvcc" writeSkewCheck="false"
> concurrencyLevel="500" />
> <transaction
> transactionManagerLookupClass="org.jboss.cache.transaction.GenericTransactionManagerLookup"
> syncRollbackPhase="false" syncCommitPhase="false" />
> <eviction wakeUpInterval="500">
> <default algorithmClass="org.jboss.cache.eviction.LRUAlgorithm"
> eventQueueSize="200000">
> <property name="maxNodes" value="5000" />
> <property name="timeToLive" value="1000" />
> </default>
> <region name="/org/jboss/data1">
> <property name="timeToLive" value="2000" />
> </region>
> <region name="/org/jboss/data2"
> algorithmClass="org.jboss.cache.eviction.FIFOAlgorithm"
> eventQueueSize="100000">
> <property name="maxNodes" value="3000" />
> <property name="minTimeToLive" value="4000" />
> </region>
> </eviction>
> <clustering mode="replication" >
> <jgroupsConfig configFile="C:/workspace/GridJBCache3/src/config/jgroups.xml" />
> </clustering>
> <loaders passivation="false" shared="false">
> <preload>
> <node fqn="/" />
> </preload>
> <loader class="org.jboss.cache.loader.JDBCCacheLoader"
> async="true" fetchPersistentState="true" ignoreModifications="true"
> purgeOnStartup="true">
> <properties>
> cache.jdbc.table.name=jbosscache
> cache.jdbc.table.create=true
> cache.jdbc.table.drop=false
> cache.jdbc.table.primarykey=jbosscache_pk
> cache.jdbc.fqn.column=fqn
> cache.jdbc.fqn.type=varchar(255)
> cache.jdbc.node.column=node
> cache.jdbc.node.type=bytea
> cache.jdbc.parent.column=parent
> cache.jdbc.driver=org.postgresql.Driver
> cache.jdbc.url=jdbc:postgresql://localhost:5432/facts7
> cache.jdbc.user=f7tms
> cache.jdbc.password=f7tms
> </properties>
> </loader>
> </loaders>
> </jbosscache>
> [/code]
> and jgroups.xml file as below
> [code]
> <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="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="discard"
> oob_thread_pool.enabled="true" oob_thread_pool.min_threads="1"
> oob_thread_pool.max_threads="8"
> oob_thread_pool.keep_alive_time="5000"
> oob_thread_pool.queue_enabled="false"
> oob_thread_pool.queue_max_size="100"
> oob_thread_pool.rejection_policy="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="3000"
> 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 /
> -->
> </config>
> [/code]
> My code start the cache as
> [code]
> package org.gridgain.examples.jbosscache;
> import java.io.File;
> import org.jboss.cache.Cache;
> import org.jboss.cache.CacheFactory;
> import org.jboss.cache.DefaultCacheFactory;
> import org.jboss.cache.Fqn;
> import org.jboss.cache.Node;
> import org.jboss.cache.config.Configuration;
> import org.jboss.cache.config.parsing.XmlConfigurationParser;
> import org.jgroups.JChannelFactory;
> public final class GridJbossCacheManager {
>     /** Cache configuration path relative to GridGain installation. */
>     public static final String CACHE_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jboss-cache.xml";
>     /** JGroups configuration path relative to GridGain installation. */
>     public static final String JGROUPS_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jgroups.xml";
>     /** JBoss Cache instance. */
>     private Cache<Long, String> cache = null;
>     /** Cache node for caching example data. */
>     private Node<Long, String> cacheRoot = null;
>     /** Singleton instance. */
>     private static GridJbossCacheManager instance = new GridJbossCacheManager();
>     /**
>      * Gets singleton.
>      *
>      * @return Singleton.
>      */
>     public static GridJbossCacheManager getInstance() {
>         return instance;
>     }
>     /**
>      * Ensure singleton.
>      */
>     private GridJbossCacheManager() {
>         // No-op.
>     }
>    
>     public void start() throws GridException {
>         File cacheCfg = new File(CACHE_CFG_PATH);
>         if (cacheCfg == null) {
>             throw new GridException("Failed to find cache configuration file: " + CACHE_CFG_PATH);
>         }
>         File jgroupsCfg = new File(JGROUPS_CFG_PATH);
>         if (jgroupsCfg == null) {
>             throw new GridException("Failed to find jgroups configuration: " + JGROUPS_CFG_PATH);
>         }
>         // Make sure JBoss Cache and GridGain are on the same "wave length".
>         JChannelFactory factory = new JChannelFactory(); //null;
>         try {
>          //factory = new JChannelFactory(jgroupsCfg);
>             factory.setMultiplexerConfig(jgroupsCfg.getCanonicalPath());
>         }
>         catch (Exception e) {
>             throw new GridException("Failed to start Data Manager.", e);
>         }
>         try {
>             XmlConfigurationParser parser = new XmlConfigurationParser();
>             // Start JBoss Cache cache with shared JGroups configuration.
>             Configuration svrCfg = parser.parseFile(cacheCfg.getCanonicalPath());
>             svrCfg.getRuntimeConfig().setMuxChannelFactory(factory);
>             CacheFactory<Long, String> dataFactory = DefaultCacheFactory.getInstance();
>             // Instantiate and start JBoss Cache.
>             cache = dataFactory.createCache(svrCfg);
>             // Cache node for storing example data.
>             cacheRoot = cache.getRoot().addChild(Fqn.fromString("/"));
>         }
>         catch (Exception e) {
>             throw new GridException("Failed to start Data Manager.", e);
>         }
>         System.out.println("JBoss Cache data manager started.");
>     }
>    
> }
> [/code]
> When i ran this program i am getting the following error
> [code]
> Exception in thread "main"
> Exception:
> ----------
> >>> Type: java.lang.Exception
> >>> Message: failed parsing C:\workspace\GridJBCache3\src\config\jgroups.xml
> >>> Stack trace:
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:216)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> Caused By:
> ----------
> >>> Type: java.io.IOException
> >>> Message: invalid XML configuration: XML protocol stack configuration does not start with a '<config>' element; maybe the XML configuration needs to be converted to the new format ?
> use 'java org.jgroups.conf.XmlConfigurator <old XML file> -new_format' to do so
> >>> Stack trace:
> >>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:476)
> >>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:462)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:213)
> >>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> >>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> [/code]
> Now i have added the
> [code]
> <protocol_stacks>
> <stack name="udp"
> description="Default: IP multicast based stack, with flow control and message bundling">
> [/code]
> to jgroups.xml. When i ran the program, its giving the following error.
> [code]
> log4j:WARN No appenders could be found for logger (org.jboss.cache.util.FileLookup).
> log4j:WARN Please initialize the log4j system properly.
> Exception in thread "main" org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
> at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:148)
> at org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(ComponentRegistry.java:1005)
> at org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegistry.java:775)
> at org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java:629)
> at org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocationDelegate.java:344)
> at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:121)
> at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:105)
> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:148)
> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:144)
> ... 9 more
> Caused by: org.jboss.cache.CacheException: Failed to create multiplexed channel using stack null
> at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:353)
> at org.jboss.cache.RPCManagerImpl.initialiseChannelAndRpcDispatcher(RPCManagerImpl.java:267)
> at org.jboss.cache.RPCManagerImpl.start(RPCManagerImpl.java:167)
> ... 14 more
> Caused by: java.lang.IllegalArgumentException: stack name and service ID have to be non null
> at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:336)
> at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:328)
> at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:349)
> ... 16 more
> [/code] 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:44:33 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 3 Jun 2009 08:44:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBID-124) Implement WS-T SAML
 Token Profile:: SAMLV2.0 validation
In-Reply-To: <26312958.1243987260389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22071469.1244033076459.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBID-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470394#action_12470394 ] 

Anil Saldhana commented on JBID-124:
------------------------------------

JBID-125 has a new AssertionUtil to check for expiry

> Implement WS-T SAML Token Profile:: SAMLV2.0 validation
> -------------------------------------------------------
>
>                 Key: JBID-124
>                 URL: https://jira.jboss.org/jira/browse/JBID-124
>             Project: JBoss Identity
>          Issue Type: Sub-task
>          Components: Identity-Federation
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha3
>
>
> The SAML token provider must be able to validate the assertions it generates. This involves validating the digital signature and also the assertion validity period (lifetime).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 08:46:08 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 3 Jun 2009 08:46:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-125) AssertionUtil
In-Reply-To: <27295921.1244032939265.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17949087.1244033168308.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-125.
------------------------------

    Resolution: Done


> AssertionUtil
> -------------
>
>                 Key: JBID-125
>                 URL: https://jira.jboss.org/jira/browse/JBID-125
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha3
>
>
> Utility to deal with assertions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:06:32 2009
From: jira-events at lists.jboss.org (Tobias Frech (JIRA))
Date: Wed, 3 Jun 2009 09:06:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBOOT-86) Reduce logging
 noise by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21515141.1244034399086.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470396#action_12470396 ] 

Tobias Frech commented on JBBOOT-86:
------------------------------------

If you do remove the JBOSS_HOME part from the output, why not simply prefix the output with JBOSS_HOME/.
That would be correct but still terse.

We would get:

JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
Bootstrap: JBOSS_HOME /server/default/conf/bootstrap.xml
Common Base: JBOSS_HOME /common/
Common Library: JBOSS_HOME /common/lib/
Server Name: JBOSS_HOME /default
Server Base: JBOSS_HOME /server/
Server Library: JBOSS_HOME /server/default/lib/
Server Config: JBOSS_HOME /default/conf/
Server Home: JBOSS_HOME /server/default/
Server Data: JBOSS_HOME /server/default/data
Server Log: JBOSS_HOME /default/log/
Server Temp: JBOSS_HOME /default/tmp 


If someone overrides any of the locations the JBOSS_HOME is automatically omitted and the attention is drawn to that entry as well.
You could have a helper class, that scans the JVM-environment for some variables and replaces the URL part with that variable name.


> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Andrew Lee Rubinger
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:08:11 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 09:08:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-987) Make many classes
	immutable
Message-ID: <31204033.1244034493328.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make many classes immutable
---------------------------

                 Key: JGRP-987
                 URL: https://jira.jboss.org/jira/browse/JGRP-987
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.x


Currently, a lot of classes could be immutable if it wasn't for the readFrom() method to initialize itself from an input stream.

However, if we had a factory, which reads and constructs immutable instances of classes, then we could turn a lot of classes into immutable classes, for example all headers should be immutable.

The code for marshalling and unmarshalling could be generated, e.g. based on an XML description of the data layout of a class.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:08:30 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 09:08:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-965) Message: headers are
	not copied
In-Reply-To: <3496327.1240914106581.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23975221.1244034512895.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-965:
--------------------------

    Fix Version/s: 3.x
                       (was: 2.8)


> Message: headers are not copied
> -------------------------------
>
>                 Key: JGRP-965
>                 URL: https://jira.jboss.org/jira/browse/JGRP-965
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.x
>
>
> Message.copy() uses Headers.copy() which does *not* copy the headers but just uses refs. This might cause unintended side effects, investigate whether this is okay or not.
> Example: we have a message in a retransmission table. We might copy it on retransmissio and change a header, that change will then be made in the original header.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:10:22 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 09:10:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-340) GossipRouter: major
	overhaul
In-Reply-To: <730198.1160401841970.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31023446.1244034624813.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-340.
---------------------------

    Resolution: Done


UDP support was left out because we're waiting for NIO in JDK 7, this will be done later

> GossipRouter: major overhaul
> ----------------------------
>
>                 Key: JGRP-340
>                 URL: https://jira.jboss.org/jira/browse/JGRP-340
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.4
>            Reporter: Bela Ban
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.8
>
>         Attachments: BCTdiff.txt, CTdiff.txt, GCdiff.txt, GossipClient.java, GossipRouter.java, GRdiff.txt
>
>
> Things to be done:
> - Use of Streamable rather than Externalizable
> - Currently we use 1 thread per request rather than a thread pool, e.g. Executor !
> - Better logging and diagnostics (JMX)
> - Use of NIO to prevent the 1 thread/client scalability issue
> - GossipClient and RouterStub should use common, shared code to communicate with the GossipRouter, currently there are exceptions because these 2 classes don't even use the same network format ! Besides, we can refactor redundant code into a common superclass
> - Use of ConnectionTable(NIO) ?
> - Add configuration options for GossipRouter's sockets, e.g. send/receive buffer size, nagling, keep_alive etc
> - Support of UDP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:12:16 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 3 Jun 2009 09:12:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6970330.1244034739089.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470400#action_12470400 ] 

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

Before closing, should we add something to the docs about this? The fact that diagnostics addresses are configurable, how to change the defaults, and that this may be required when running in an IPv6 environment?  

If you don't change the defaults for diagnostics, you get the unenviable situation where the user intends to use IPv6 and takes care to change his bind and multicast address, but diagnostics still uses IPv4. If the user has only adjusted his IPv6 firewall, the IPv4 diagnostics packets might not get through, and he may wonder why JGroups works but probe does not.

The firewall issue may come into play with other non-diagnostics IPv4 defaults which are getting picked up, if there are any. 
 



> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:14:08 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 3 Jun 2009 09:14:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13352332.1244034850497.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470401#action_12470401 ] 

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

And what about the errors above trying to bind to virtual interfaces? 

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:20:18 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 09:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <748502.1244035218274.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470402#action_12470402 ] 

Bela Ban commented on JGRP-978:
-------------------------------

A stupid idea: why don't we pick an IPv4 multicast address *and* an IPv6 multicast address for the diagnostics address ? First we try to bind to the IPv4 mcast address, if this fails we fall back to binding to the IPv6 mcast address. Probe then also mcasts packets to both the IPv4 and IPv6 addresses...

Of course, we should suppress some of the errors that will inevitable show up...

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:37:57 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 3 Jun 2009 09:37:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26643849.1244036277505.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470408#action_12470408 ] 

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

Yes, if we are going to use defaults, we probably need defaults for both Pv4 and IPv6 now.

But doesn't this leave us in the same position as before: a user binds and sets mcast to IPv6 addresses, but diagnostics will try IPv4 first and succeed, leaving a JGroups instance using both IPv4 and IPv6.

Can't we use the bind address and/or mcast address which the user supplies (or does not) to choose which type of diagnostics address (IPv4 or IPv6) to use?  So, when JGroups starts up, we set a flag isIPv6, as with isLinux, isHPUX, etc., based on the bind and/or multicast address specified. The only time we would have a problem is when they typed in an IPv4 bind address with an IPv6 multicast address, say, and that might reasonably generate an error?




> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:45:36 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 3 Jun 2009 09:45:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4181544.1244036739468.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470409#action_12470409 ] 

Bela Ban commented on JGRP-978:
-------------------------------

OK, so you want to do the following: if the bind_addr is (not null) and is an Inet6Address, then pick the IPv6 default for the diagnostics multicast address, else fall back to the IPv4 address. I think that's fine. Can you do that ?

What do we do on the probe.sh side if -mcast_addr is not specified on the command line ? By default try the IPv4 mcast address ? Or both the IPv4 and IPv6 default mcast addresses ?

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:55:01 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 3 Jun 2009 09:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-986) FLUSH: relax event
 sequencing for a joining member
In-Reply-To: <16765612.1244019962699.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6597142.1244037305268.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic resolved JGRP-986.
--------------------------------------

    Resolution: Done


Added javadoc to ExtendedMembershipListener


Resolved on HEAD (JGroups 2.8)

Revision Changes Path
1.134 +1 -4 JGroups/src/org/jgroups/protocols/pbcast/FLUSH.java



Resolved on 2.6 Branch (Included in 2.6.11 release)

1.82.2.22 +0 -7 JGroups/src/org/jgroups/protocols/pbcast/FLUSH.java

> FLUSH: relax event sequencing for a joining member
> --------------------------------------------------
>
>                 Key: JGRP-986
>                 URL: https://jira.jboss.org/jira/browse/JGRP-986
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.10, 2.8
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>
> There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a switch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This switch was introduced to always enforce a strict order between view, unblock and message M. 
> If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:59:32 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 3 Jun 2009 09:59:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3759133.1244037572825.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470416#action_12470416 ] 

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

I'll check it out. May take a couple of days, as i've got EAP stuff to do.

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 09:59:45 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 3 Jun 2009 09:59:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-984) JGroups can not
 parse IPV6 literals in TCPPING protocol configuration
In-Reply-To: <7188979.1242741125294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17114115.1244037588440.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470417#action_12470417 ] 

Brian Stansberry commented on JGRP-984:
---------------------------------------

Thanks. I copied your comment to the original issue JBPAPP-2013 and asked Dominik to reply here if there is anything further.

> JGroups can not parse IPV6 literals in TCPPING protocol configuration
> ---------------------------------------------------------------------
>
>                 Key: JGRP-984
>                 URL: https://jira.jboss.org/jira/browse/JGRP-984
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.6
>            Reporter: Brian Stansberry
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> ON JBPAPP-2013 Dominik Pospisil reports the IPv6 address parsing fix in 2.4.6 doesn't handle TCPPING:
> Both
> <TCPPING initial_hosts="::1[7810],fec0::f101:21a:a0ff:fea0:d745[7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> and
> <TCPPING initial_hosts="[::1][7810],[fec0::f101:21a:a0ff:fea0:d745][7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> fails with:
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "::1"
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "fec0::f101:21a:a0ff:fea0:d745"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:10:19 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 3 Jun 2009 10:10:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBOOT-88)
 ProfileServiceBootstrap: Failed to build ManagedDeployment
In-Reply-To: <10128448.1244015996530.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19566180.1244038227259.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBBOOT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470420#action_12470420 ] 

Andrew Lee Rubinger commented on JBBOOT-88:
-------------------------------------------

What are the steps taken to reproduce the above?  Is this simply on boot?

This should likely be filed under JBAS project; ProfileServiceBootstrap is part of the AS "system" module.



> ProfileServiceBootstrap: Failed to build ManagedDeployment
> ----------------------------------------------------------
>
>                 Key: JBBOOT-88
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-88
>             Project: JBoss Bootstrap
>          Issue Type: Bug
>         Environment: JBoss AS 5.1.0, WinXP, jdk 1.6.0u13
>            Reporter: Ondrej Medek
>            Assignee: Andrew Lee Rubinger
>         Attachments: boot.log
>
>
> I see two exception in my boot.log: DEBUG [ProfileServiceBootstrap] Failed to build ManagedDeployment for:
> 1) AbstractKernelDeployment at 1cd427a{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml installed=true beanFactories=[AbstractBeanMetaData at c791f4{name=VFSCache bean=null properties=[realCache, permanentRoots] constructor=AbstractConstructorMetaData at 198defc{parameters=[null] factoryClass=org.jboss.virtual.spi.cache.VFSCacheFactory factoryMethod=getInstance} autowireCandidate=true start=AbstractLifecycleMetaData at 1579a30{ whenRequired=ControllerState at 3f58bb{Start} parameters= }}, AbstractBeanMetaData at da9067{name=VfsNamesExceptionHandler bean=org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler properties= constructor=AbstractConstructorMetaData at 13e9934{parameters=[java.lang.String]} autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 2) AbstractKernelDeployment at 17044c5{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml installed=true beanFactories=[AbstractBeanMetaData at 1b2e44d{name=LogBridgeHandler bean=org.jboss.logbridge.LogBridgeHandler properties= constructor=null autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:36:40 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Wed, 3 Jun 2009 10:36:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBOOT-88)
 ProfileServiceBootstrap: Failed to build ManagedDeployment
In-Reply-To: <10128448.1244015996530.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <558162.1244039802016.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBBOOT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470431#action_12470431 ] 

Ondrej Medek commented on JBBOOT-88:
------------------------------------

Yes, just simple boot of the "default" server configuration, i.e. bin\run.bat, that's it.

How to move this bug to the proper project?

> ProfileServiceBootstrap: Failed to build ManagedDeployment
> ----------------------------------------------------------
>
>                 Key: JBBOOT-88
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-88
>             Project: JBoss Bootstrap
>          Issue Type: Bug
>         Environment: JBoss AS 5.1.0, WinXP, jdk 1.6.0u13
>            Reporter: Ondrej Medek
>            Assignee: Andrew Lee Rubinger
>         Attachments: boot.log
>
>
> I see two exception in my boot.log: DEBUG [ProfileServiceBootstrap] Failed to build ManagedDeployment for:
> 1) AbstractKernelDeployment at 1cd427a{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml installed=true beanFactories=[AbstractBeanMetaData at c791f4{name=VFSCache bean=null properties=[realCache, permanentRoots] constructor=AbstractConstructorMetaData at 198defc{parameters=[null] factoryClass=org.jboss.virtual.spi.cache.VFSCacheFactory factoryMethod=getInstance} autowireCandidate=true start=AbstractLifecycleMetaData at 1579a30{ whenRequired=ControllerState at 3f58bb{Start} parameters= }}, AbstractBeanMetaData at da9067{name=VfsNamesExceptionHandler bean=org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler properties= constructor=AbstractConstructorMetaData at 13e9934{parameters=[java.lang.String]} autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 2) AbstractKernelDeployment at 17044c5{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml installed=true beanFactories=[AbstractBeanMetaData at 1b2e44d{name=LogBridgeHandler bean=org.jboss.logbridge.LogBridgeHandler properties= constructor=null autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:49:23 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 3 Jun 2009 10:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1842)
 ClusteredIsLocalInterceptor finds unstarted beans
Message-ID: <10481921.1244040566021.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClusteredIsLocalInterceptor finds unstarted beans
-------------------------------------------------

                 Key: EJBTHREE-1842
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1842
             Project: EJB 3.0
          Issue Type: Bug
          Components: interceptors
    Affects Versions: AS 4.2.2.GA
            Reporter: Brian Stansberry
            Assignee: Paul Ferraro


ClusteredIsLocalInterceptor determines whether a bean is available locally by checking the Ejb3Registry. Problem is beans are registered early in the deployment process, before they are started.

In the related forum thread pawel.wyrwinski reports how this particularly causes problems when an @Depends("jboss.ha:service=HASingletonDeployer,type=Barrier") annotation is used to make a bean act as an HASingleton. The bean is included in the Ejb3Registry on all nodes but is only started on one.

A logically obvious solution would be to check whether the target container is started before invoking locally. Unfortunately, AFAICT Container and its subclasses do not expose any method to support such a check.

Pawel reported this against 4.2.2 so that the "Affects Version" I used, but a quick code check leads me to believe it still exists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:51:54 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 3 Jun 2009 10:51:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14621886.1244040716830.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-6808:
---------------------------------

    Priority: Critical  (was: Major)


> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:52:51 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 10:52:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6939) after stopping a
 Topic or Queue
 via the stop operation, calling getRunState() on the corresponding
 component returns RunState.RUNNING, rather than RunState.STOPPED
In-Reply-To: <3464546.1242671225528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31560105.1244040780232.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6939:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> after stopping a Topic or Queue via the stop operation, calling getRunState() on the corresponding component returns RunState.RUNNING, rather than RunState.STOPPED
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6939
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6939
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Ian Springer
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:53:42 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 10:53:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6960) once a Topic or
 Queue has been
 stopped via the 'stop' operation, none of its operations or properties
 work, and thus it cannot be restarted using the 'start' operation
In-Reply-To: <11989891.1242832445240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19229992.1244040830281.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6960:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> once a Topic or Queue has been stopped via the 'stop' operation, none of its operations or properties work, and thus it cannot be restarted using the 'start' operation
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6960
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6960
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Ian Springer
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:55:26 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 10:55:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6242) invoke() for
 "listFormattedSubPoolStatistics" ManagedOperation on datasources and
 connection factory ManagedComponents returns a MetaValue with the wrong
 MetaType
In-Reply-To: <18716075.1227550606927.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27741102.1244040928841.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6242:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


I'm not sure if this is still an issue. We need to try to reproduce it w/ the latest bits.



> invoke() for "listFormattedSubPoolStatistics" ManagedOperation on datasources and connection factory ManagedComponents returns a MetaValue with the wrong MetaType
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6242
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6242
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBAS5 Hudson build dated 200811210604
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This is another case of the data not matching the metadata.
> operation.getReturnType() returns a MutableCompositeMetaType w/ typeName java.lang.Object. However, invoke() is returning a SimpleMetaType.STRING (with value e.g. "Sub Pool Statistics: \nSub Pool Count: 0\n------------------------------------------------------\n"). 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:56:28 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 3 Jun 2009 10:56:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-6998)
 ProfileServiceBootstrap: Failed to build ManagedDeployment
In-Reply-To: <10128448.1244015996530.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16341337.1244040991594.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger moved JBBOOT-88 to JBAS-6998:
-------------------------------------------------

     Project: JBoss Application Server  (was: JBoss Bootstrap)
         Key: JBAS-6998  (was: JBBOOT-88)
    Security: Public


> ProfileServiceBootstrap: Failed to build ManagedDeployment
> ----------------------------------------------------------
>
>                 Key: JBAS-6998
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6998
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBoss AS 5.1.0, WinXP, jdk 1.6.0u13
>            Reporter: Ondrej Medek
>            Assignee: Andrew Lee Rubinger
>         Attachments: boot.log
>
>
> I see two exception in my boot.log: DEBUG [ProfileServiceBootstrap] Failed to build ManagedDeployment for:
> 1) AbstractKernelDeployment at 1cd427a{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml installed=true beanFactories=[AbstractBeanMetaData at c791f4{name=VFSCache bean=null properties=[realCache, permanentRoots] constructor=AbstractConstructorMetaData at 198defc{parameters=[null] factoryClass=org.jboss.virtual.spi.cache.VFSCacheFactory factoryMethod=getInstance} autowireCandidate=true start=AbstractLifecycleMetaData at 1579a30{ whenRequired=ControllerState at 3f58bb{Start} parameters= }}, AbstractBeanMetaData at da9067{name=VfsNamesExceptionHandler bean=org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler properties= constructor=AbstractConstructorMetaData at 13e9934{parameters=[java.lang.String]} autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 2) AbstractKernelDeployment at 17044c5{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml installed=true beanFactories=[AbstractBeanMetaData at 1b2e44d{name=LogBridgeHandler bean=org.jboss.logbridge.LogBridgeHandler properties= constructor=null autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:57:53 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 10:57:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-5452)
 ManagementView.getDeployment
 should always at least return a structural view of a deployment
In-Reply-To: <8840076.1208274234767.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1706745.1244041075881.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-5452:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> ManagementView.getDeployment should always at least return a structural view of a deployment
> --------------------------------------------------------------------------------------------
>
>                 Key: JBAS-5452
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5452
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services, ProfileService
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently the ManagementView.getDeployment(String name, DeploymentPhase phase) api requires a deployment to have @ManagementDeployment/@ManagementObject/@ManagementComponent annotations to build any type of view of the deployment. There should be a basic structure view returned in the absence of any @ManagementObject/@ManagementComponent info. It would just be the structure view with a ManagedDeployment graph that mirrors the StructureMetaData.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 10:58:46 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 3 Jun 2009 10:58:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6998)
 ProfileServiceBootstrap: Failed to build ManagedDeployment
In-Reply-To: <10128448.1244015996530.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8861294.1244041134429.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470436#action_12470436 ] 

Andrew Lee Rubinger commented on JBAS-6998:
-------------------------------------------

Recommend opening a topic in the AS5 User's Forum: http://www.jboss.org/index.html?module=bb&op=viewforum&f=287

> ProfileServiceBootstrap: Failed to build ManagedDeployment
> ----------------------------------------------------------
>
>                 Key: JBAS-6998
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6998
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBoss AS 5.1.0, WinXP, jdk 1.6.0u13
>            Reporter: Ondrej Medek
>            Assignee: Andrew Lee Rubinger
>         Attachments: boot.log
>
>
> I see two exception in my boot.log: DEBUG [ProfileServiceBootstrap] Failed to build ManagedDeployment for:
> 1) AbstractKernelDeployment at 1cd427a{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml installed=true beanFactories=[AbstractBeanMetaData at c791f4{name=VFSCache bean=null properties=[realCache, permanentRoots] constructor=AbstractConstructorMetaData at 198defc{parameters=[null] factoryClass=org.jboss.virtual.spi.cache.VFSCacheFactory factoryMethod=getInstance} autowireCandidate=true start=AbstractLifecycleMetaData at 1579a30{ whenRequired=ControllerState at 3f58bb{Start} parameters= }}, AbstractBeanMetaData at da9067{name=VfsNamesExceptionHandler bean=org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler properties= constructor=AbstractConstructorMetaData at 13e9934{parameters=[java.lang.String]} autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 2) AbstractKernelDeployment at 17044c5{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml installed=true beanFactories=[AbstractBeanMetaData at 1b2e44d{name=LogBridgeHandler bean=org.jboss.logbridge.LogBridgeHandler properties= constructor=null autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:02:11 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 11:02:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6524) BeanMetaDataICF
 logging many exceptions at debug while retrieving properties
In-Reply-To: <17044868.1234985744567.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17253558.1244041333921.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6524:
-------------------------------

    Complexity: Low
        Labels: EmbJopr1_3 ProfileService  (was: )


> BeanMetaDataICF logging many exceptions at debug while retrieving properties
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-6524
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6524
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.Beta1
>         Environment: jboss-5.1.x-r84398.zip
>            Reporter: Charles Crouch
>            Assignee: Scott M Stark
>            Priority: Optional
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: BeanMetaDataICF-exceptions.log
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> I'm seeing many exceptions (at DEBUG level) in the server.log when the embedded console is starting up and doing its initial discovery scan, i.e. asking the profile service for a list of stuff which is deployed. I've attached a snippet of the log.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:03:50 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 11:03:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6720) Make sure that the
 metrics for
 Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as
 ViewUse.STATISTIC
In-Reply-To: <7508166.1238615242987.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24766599.1244041433977.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-6720:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> Make sure that the metrics for Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as ViewUse.STATISTIC
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6720
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6720
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: JBoss AS Branch_5_x r86586, embjopr r266
>            Reporter: Farah Juma
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Steps to reproduce:
> Create a new Topic or Queue using Embedded Jopr. Send some messages to the Topic or Queue. Navigate to the "Metrics" tab for the resource. The metrics do not get updated to reflect this change. All the values are 0.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:06:17 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 11:06:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1436) Improved management
Message-ID: <22753413.1244041589934.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-1436:
-------------------------------

    Affects Version/s: JBossAS-5.1.0.GA
           Complexity: Medium
             Priority: Major  (was: Minor)


> Improved management
> -------------------
>
>                 Key: JBAS-1436
>                 URL: https://jira.jboss.org/jira/browse/JBAS-1436
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Adrian Brock
>            Assignee: Vicky Kak
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Forum Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48682
> **This is a holder issue. Each section should be raised as a new issue as it is 
> developed with a link from this issue.**
> There are a number of areas in JCA that need better management capabilities.
> Some of these stats may also reveal the need for new configuration/tuning parameters.
> In core JCA:
> 1) Better visibility on the ManagedConnectionFactory.
> This is currently a DynamicMBean that provides basic config parameters, but we could also
> provide a proxy/wrapper to provide statistics of operations on the factory and its 
> ManagedConnections.
> a) createManagedConnections
> b) matchManagedConnections
> c) events on from the listeners
> 2) Better visibility of the Pool(s)
> Only top level statistics are provided (you cannot see the subpools).
> The statistics are also not synchronized with the pool (for performance reasons
> and also the fact that each stat is retrieved on individual MBean getAttribute requests)
> Additional statistics could include wait times when requests are waiting on an empty pool,
> idle time of unused connections, etc.
> 3) Better visibility of the ConnectionManager
> Currently this has no visibility for management.
> Its main responsibilties are transactions enlistment and security.
> e.g. This could show how long is wasted because <track-connection-by-tx/> does not
> return the connection the pool until transaction completion.
> 4) JDBC resource adapter
> PreparedStatementCache stats
> Query time stats
> etc.
> 5) JMS resource adapter
> Message send/receive stats
> 6) Inbound messaging
> Stats for message delivery
> 7) Transaction inflow
> Stats for transaction inflow and also display a list of current inbound transactions
> 8) Work management
> Stats for the work management pools and timers

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:07:48 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 3 Jun 2009 11:07:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6984) trying to remotely
 retrieve
 statistic properties (e.g. rollbackCount) from MCBean:JTA managed
 components results in "ClassNotFoundException:
 com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
In-Reply-To: <11628190.1243511107980.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24507182.1244041673300.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-6984:
---------------------------------

    Priority: Critical  (was: Major)


> trying to remotely retrieve statistic properties (e.g. rollbackCount) from MCBean:JTA managed components results in "ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6984
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6984
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>
> 2009-05-28 07:40:01,544 ERROR [ResourceContainer.invoker.daemon-364] (org.rhq.plugins.jbossas5.ApplicationServerComponent)- Failed to obtain metric 'MCBean|JTA|*|rollbackCount'.
> java.lang.IllegalStateException: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:160)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
> 	at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
> 	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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> 	at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1462)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1312)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	... 11 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:09:18 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 3 Jun 2009 11:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1618)
 Connection.close should be synchronous
In-Reply-To: <18244331.1241566547167.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17596129.1244041766729.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1618:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Connection.close should be synchronous
> --------------------------------------
>
>                 Key: JBMESSAGING-1618
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1618
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Clebert Suconic
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0 Beta
>
>
> This is related to http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154639
> When connection.close() is called, the server needs some time before releasing the connection.
> There is a FIXME block on ReplicationAwareJMSServerControlWrapperTest::testListRemoteAddresses for this:
>       // FIXME: Closing a connection should be Synchronous
>       //        Remove this loop block when https://jira.jboss.org/jira/browse/JBMESSAGING-1618 is done
>       long timeout = System.currentTimeMillis() + 5000;
>       while (timeout > System.currentTimeMillis() && liveServerControl.listRemoteAddresses().length != 0)
>       {
>          Thread.sleep(10);
>       }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:11:43 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 3 Jun 2009 11:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-6999) expose MOs for EJB3
 MDBs w/ some metrics
Message-ID: <23501033.1244041905722.JavaMail.jira@cloud.prod.atl2.jboss.com>

expose MOs for EJB3 MDBs w/ some metrics
----------------------------------------

                 Key: JBAS-6999
                 URL: https://jira.jboss.org/jira/browse/JBAS-6999
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-5.2.0.Beta1


<pilhuhn> Do you also plan to list MDBs so that they can at least be detected?
<ALR> pilhuhn: I hadn't, but I can add that.  What would you like exposed for MDB?
<pilhuhn> metrics like on the jmx console would be cool, but just listing them as ManagedComponent within a EJB jar would be great - they are already in the KnownComponentTypes :)
<ALR> pilhuhn: To list as a ManagedComponent wouldn't I need to register some @ManagementObject ?  Just some stub thing?
<pilhuhn> aehm .. :)
<ALR> pilhuhn: I've found some stats I can expose, actually, without touching the ejb3-core, which has been my aim thus far. :)  I'll do it.
<pilhuhn> Great - JOPR-203 has a EAR attached with a MDB in it - and the jxm-console shows keepalive millis, stats, min pool size, max pool size, delivery active and max messages


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:12:45 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 3 Jun 2009 11:12:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1618)
 Connection.close should be synchronous
In-Reply-To: <18244331.1241566547167.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27657547.1244041978123.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1618.
------------------------------------

    Resolution: Done


fixed in the trunk

> Connection.close should be synchronous
> --------------------------------------
>
>                 Key: JBMESSAGING-1618
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1618
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Clebert Suconic
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0 Beta
>
>
> This is related to http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154639
> When connection.close() is called, the server needs some time before releasing the connection.
> There is a FIXME block on ReplicationAwareJMSServerControlWrapperTest::testListRemoteAddresses for this:
>       // FIXME: Closing a connection should be Synchronous
>       //        Remove this loop block when https://jira.jboss.org/jira/browse/JBMESSAGING-1618 is done
>       long timeout = System.currentTimeMillis() + 5000;
>       while (timeout > System.currentTimeMillis() && liveServerControl.listRemoteAddresses().length != 0)
>       {
>          Thread.sleep(10);
>       }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:15:36 2009
From: jira-events at lists.jboss.org (Travis Scheponik (JIRA))
Date: Wed, 3 Jun 2009 11:15:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2102) Expert evaluate()
 does *not* throw NPE
Message-ID: <5024417.1244042144647.JavaMail.jira@cloud.prod.atl2.jboss.com>

Expert evaluate() does *not* throw NPE
--------------------------------------

                 Key: JBRULES-2102
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2102
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.0.FINAL
         Environment:  java 1.6.0_11, Ubuntu
            Reporter: Travis Scheponik
            Assignee: Mark Proctor


http://pastebin.com/m1dffefc4 <-- offending method within Expert

example ObjectA( a:member1, b:member2, a > b)  <-- this crashes if b is null

example: ObjectA(a:member1, b:member2, eval(a > b )) <-- afaik, this *should* crash  if a or b is null

This was requested to be posted by: etirelli and bjornelo

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:17:10 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 3 Jun 2009 11:17:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6999) expose MOs for
 EJB3 MDBs w/ some metrics
In-Reply-To: <23501033.1244041905722.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16824422.1244042233324.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470440#action_12470440 ] 

Andrew Lee Rubinger commented on JBAS-6999:
-------------------------------------------

Committed in r89742.

> expose MOs for EJB3 MDBs w/ some metrics
> ----------------------------------------
>
>                 Key: JBAS-6999
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6999
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> <pilhuhn> Do you also plan to list MDBs so that they can at least be detected?
> <ALR> pilhuhn: I hadn't, but I can add that.  What would you like exposed for MDB?
> <pilhuhn> metrics like on the jmx console would be cool, but just listing them as ManagedComponent within a EJB jar would be great - they are already in the KnownComponentTypes :)
> <ALR> pilhuhn: To list as a ManagedComponent wouldn't I need to register some @ManagementObject ?  Just some stub thing?
> <pilhuhn> aehm .. :)
> <ALR> pilhuhn: I've found some stats I can expose, actually, without touching the ejb3-core, which has been my aim thus far. :)  I'll do it.
> <pilhuhn> Great - JOPR-203 has a EAR attached with a MDB in it - and the jxm-console shows keepalive millis, stats, min pool size, max pool size, delivery active and max messages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:19:47 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 3 Jun 2009 11:19:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2102) Expert
 evaluate() does *not* throw NPE
In-Reply-To: <5024417.1244042144647.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6715368.1244042393550.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned JBRULES-2102:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> Expert evaluate() does *not* throw NPE
> --------------------------------------
>
>                 Key: JBRULES-2102
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2102
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.0.FINAL
>         Environment:  java 1.6.0_11, Ubuntu
>            Reporter: Travis Scheponik
>            Assignee: Edson Tirelli
>
> http://pastebin.com/m1dffefc4 <-- offending method within Expert
> example ObjectA( a:member1, b:member2, a > b)  <-- this crashes if b is null
> example: ObjectA(a:member1, b:member2, eval(a > b )) <-- afaik, this *should* crash  if a or b is null
> This was requested to be posted by: etirelli and bjornelo

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:21:25 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 3 Jun 2009 11:21:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6999) expose MOs for
 EJB3 MDBs w/ some metrics
In-Reply-To: <23501033.1244041905722.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28401386.1244042489079.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470442#action_12470442 ] 

Andrew Lee Rubinger commented on JBAS-6999:
-------------------------------------------

Example debug output of an MDB: 

ManagedDeployment: vfszip:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/mdb-test.jar/ +++ ManagedComponent(name=OverrideDefaultedQueueTestMDB-metrics-instance, type=(ComponentType{type=EJB3, subtype=MDB}), compName=OverrideDefaultedQueueTestMDB-metrics-instance, attachment: org.jboss.ejb3.metrics.deployer.BasicMessageDrivenInstanceMetrics ++++++ properties: [maxMessages, deliveryActive, invokeStats, maxPoolSize, keepAliveMillis, minPoolSize] 

> expose MOs for EJB3 MDBs w/ some metrics
> ----------------------------------------
>
>                 Key: JBAS-6999
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6999
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> <pilhuhn> Do you also plan to list MDBs so that they can at least be detected?
> <ALR> pilhuhn: I hadn't, but I can add that.  What would you like exposed for MDB?
> <pilhuhn> metrics like on the jmx console would be cool, but just listing them as ManagedComponent within a EJB jar would be great - they are already in the KnownComponentTypes :)
> <ALR> pilhuhn: To list as a ManagedComponent wouldn't I need to register some @ManagementObject ?  Just some stub thing?
> <pilhuhn> aehm .. :)
> <ALR> pilhuhn: I've found some stats I can expose, actually, without touching the ejb3-core, which has been my aim thus far. :)  I'll do it.
> <pilhuhn> Great - JOPR-203 has a EAR attached with a MDB in it - and the jxm-console shows keepalive millis, stats, min pool size, max pool size, delivery active and max messages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:23:31 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Bj=C3=83=C2=B8rn_Erik_L=C3=83=C2=B8mo_=28JIRA=29?=)
Date: Wed, 3 Jun 2009 11:23:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2102) Expert
 evaluate() does *not* throw NPE
In-Reply-To: <5024417.1244042144647.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3131094.1244042618505.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470443#action_12470443 ] 

Bj??rn Erik L??mo commented on JBRULES-2102:
--------------------------------------------

In the aforementioned example, if both members are Integer objects, one of them being a nullpointer: If the right hand side of an Integer > Integer comparison is a nullpointer, drools throws a NPE. If the left hand side is null, it works fine. There's a check missing for null values on object2 in this function:

public boolean evaluate(InternalWorkingMemory workingMemory,
                                final InternalReadAccessor extractor1,
                                final Object object1,
                                final InternalReadAccessor extractor2, final Object object2) {
       if( extractor1.isNullValue( workingMemory, object1 ) ) {
                return false;
        }
        return extractor1.getIntValue( workingMemory, object1 ) > extractor2.getIntValue( workingMemory, object2 );
}

Etirelli can probably fill in the rest.

> Expert evaluate() does *not* throw NPE
> --------------------------------------
>
>                 Key: JBRULES-2102
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2102
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.0.FINAL
>         Environment:  java 1.6.0_11, Ubuntu
>            Reporter: Travis Scheponik
>            Assignee: Edson Tirelli
>
> http://pastebin.com/m1dffefc4 <-- offending method within Expert
> example ObjectA( a:member1, b:member2, a > b)  <-- this crashes if b is null
> example: ObjectA(a:member1, b:member2, eval(a > b )) <-- afaik, this *should* crash  if a or b is null
> This was requested to be posted by: etirelli and bjornelo

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Jun  3 11:26:26 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 3 Jun 2009 11:26:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2738166.1244042789759.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned JBAS-6808:
--------------------------------------

    Assignee: Brian Stansberry  (was: Scott M Stark)


I'll handle this.

> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 11:29:58 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 3 Jun 2009 11:29:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6877) EJB3 Entity Cache
	Metrics
In-Reply-To: <13995931.1241642506748.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14917937.1244043006729.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated JBAS-6877:
-----------------------------------

    Summary: EJB3 Entity Cache Metrics  (was: EJB3 Cache Metrics)


> EJB3 Entity Cache Metrics
> -------------------------
>
>                 Key: JBAS-6877
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6877
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>            Reporter: Andrew Lee Rubinger
>            Assignee: Brian Stansberry
>             Fix For: Backlog
>
>
> These statistics must be reflected in the admin-console/Jopr.
> Split from JBAS-6624:
> EJB3 Entity Tree Cache (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache-->
> <metric property="NumberOfLocksHeld" displayType="summary"/>
>          <metric property="NumberOfNodes" displayType="summary"/>
> EJB3 Entity Tree Cache Interceptor (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache,treecache-interceptor=CacheMgmtInterceptor-->
>             <metric property="HitMissRatio" displayType="summary" units="percentage"
>                     description="Returns the hit/miss ratio for the cache. This ratio is defined as hits/(hits + misses)."/>
>             <metric property="ReadWriteRatio" displayType="summary" units="percentage"
>                     description="Returns the read/write ratio for the cache. This ratio is defined as (hits + misses)/stores."/>
>             <metric property="Hits" displayType="summary"/>
>             <metric property="Misses" displayType="summary"/>
>             <metric property="Evictions" displayType="summary"/>
>             <metric property="NumberOfLocksHeld"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="AverageWriteTime" units="milliseconds"/>
>             <metric property="TimeSinceReset" units="seconds"/>
>             <metric property="AverageReadTime" units="milliseconds"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="Stores"/>
>             <metric property="NumberOfAttributes"/>
>             <metric property="ElapsedTime" units="milliseconds"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 12:28:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 3 Jun 2009 12:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2102) Expert evaluate()
 does *not* throw NPE
In-Reply-To: <5024417.1244042144647.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33500717.1244046536567.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2102.
----------------------------------

    Fix Version/s: 5.1.0.M1
       Resolution: Done


Fixed. Thanks for reporting.

> Expert evaluate() does *not* throw NPE
> --------------------------------------
>
>                 Key: JBRULES-2102
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2102
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.0.FINAL
>         Environment:  java 1.6.0_11, Ubuntu
>            Reporter: Travis Scheponik
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> http://pastebin.com/m1dffefc4 <-- offending method within Expert
> example ObjectA( a:member1, b:member2, a > b)  <-- this crashes if b is null
> example: ObjectA(a:member1, b:member2, eval(a > b )) <-- afaik, this *should* crash  if a or b is null
> This was requested to be posted by: etirelli and bjornelo

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 13:07:14 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 3 Jun 2009 13:07:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBWEB-140) Define javac target
 for build consistency
Message-ID: <3295821.1244048854856.JavaMail.jira@cloud.prod.atl2.jboss.com>

Define javac target for build consistency
-----------------------------------------

                 Key: JBWEB-140
                 URL: https://jira.jboss.org/jira/browse/JBWEB-140
             Project: JBoss Web
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Core
    Affects Versions: JBossWeb-2.0.0.GA_CP09
            Reporter: Mike Millson
            Assignee: Mike Millson


Currently the build will target the JVM version being used to run the ant build task. Add the ability to build with JDK 1.6 by specifying the javac target to 1.5.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 13:08:57 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 3 Jun 2009 13:08:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-140) Define javac target
 for build consistency
In-Reply-To: <3295821.1244048854856.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29577220.1244048938158.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-140:
-------------------------------

    Attachment: build.xml.patch


Proposed patch. 

ant.build.javac.target is also defined because it has been observed that the javac target is ignored with ant 1.7 and FC10 x86-64 OpenJDK 64-Bit. With ant 1.7, the javac default target is ant.build.javac.target, so this is a workaround for those cases.

> Define javac target for build consistency
> -----------------------------------------
>
>                 Key: JBWEB-140
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-140
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Mike Millson
>         Attachments: build.xml.patch
>
>
> Currently the build will target the JVM version being used to run the ant build task. Add the ability to build with JDK 1.6 by specifying the javac target to 1.5.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 13:13:25 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 3 Jun 2009 13:13:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1558)
 @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) ignored on
 MDB onMessage
In-Reply-To: <6182654.1225298240959.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22292528.1244049205080.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated EJBTHREE-1558:
------------------------------------

      Component/s: core
    Fix Version/s: 1.1.7


> @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) ignored on MDB onMessage
> --------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1558
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1558
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: AS 4.2.2.GA
>            Reporter: Justin Bertram
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.7
>
>
> Even when putting:
>   @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
> on the onMessage method of an MDB a transaction is still started.  This can be verified by using a simple MDB that sleeps for longer than the transaction timeout (300 seconds by default).  For example:
>   import javax.ejb.ActivationConfigProperty;
>   import javax.ejb.MessageDriven;
>   import javax.ejb.TransactionAttribute;
>   import javax.ejb.TransactionAttributeType;
>   import javax.jms.Message;
>   import javax.jms.MessageListener;
>   
>   import org.apache.log4j.Logger;
>   
>   @MessageDriven(activationConfig = { 
>   		@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), 
>   		@ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/A"), 
>   		@ActivationConfigProperty(propertyName = "maxSession", propertyValue = "3") })
>   public class ExampleEJB3MDB implements MessageListener {
>   	private static final Logger logger = Logger.getLogger(ExampleEJB3MDB.class);
>   
>   	@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
>   	public void onMessage(Message m) {
>   		logger.info("message received, waiting for 10 mins...");
>   
>   		try {
>   			Thread.sleep(600000); // 10 mins
>   
>   		} catch (InterruptedException e) {
>   		}
>   
>   		logger.info("finished waiting");
>   	}
>   }
> When a message is sent to "queue/A" and the MDB picks it up it prints "message received, waiting for 10 mins..." in the log.  After 5 minutes (300 seconds) the message appears in the log again because the transaction has timed-out and the message has been redelivered.
> I believe the problem lies in org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory in the isDeliveryTransacted method.  Here is that method [1]:
>   public boolean isDeliveryTransacted(Method method) throws NoSuchMethodException
>      {
>         TransactionManagementType mtype = TxUtil.getTransactionManagementType(container);
>         if (mtype == javax.ejb.TransactionManagementType.BEAN) return false;
>   
>   
>         TransactionAttribute attr = (TransactionAttribute)container.resolveAnnotation(method, TransactionAttribute.class);
>         if (attr == null)
>         {
>            attr =(TransactionAttribute)container.resolveAnnotation(TransactionAttribute.class);
>         }
>         TransactionAttributeType type = TransactionAttributeType.REQUIRED;
>         if (attr != null) type = attr.value();
>         return type == javax.ejb.TransactionAttributeType.REQUIRED;
>      }
> It seems there should be an explicit check for TransactionAttributeType.NOT_SUPPORTED.  If the MDB uses @TransactionManagement(TransactionManagementType.BEAN) then the redelivery doesn't occur (since the code explicitly checks this attribute and returns false if it is present).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 13:13:25 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 3 Jun 2009 13:13:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1558)
 @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) ignored on
 MDB onMessage
In-Reply-To: <6182654.1225298240959.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26483680.1244049205255.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved EJBTHREE-1558.
-------------------------------------

    Resolution: Done


> @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) ignored on MDB onMessage
> --------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1558
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1558
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: AS 4.2.2.GA
>            Reporter: Justin Bertram
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.7
>
>
> Even when putting:
>   @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
> on the onMessage method of an MDB a transaction is still started.  This can be verified by using a simple MDB that sleeps for longer than the transaction timeout (300 seconds by default).  For example:
>   import javax.ejb.ActivationConfigProperty;
>   import javax.ejb.MessageDriven;
>   import javax.ejb.TransactionAttribute;
>   import javax.ejb.TransactionAttributeType;
>   import javax.jms.Message;
>   import javax.jms.MessageListener;
>   
>   import org.apache.log4j.Logger;
>   
>   @MessageDriven(activationConfig = { 
>   		@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), 
>   		@ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/A"), 
>   		@ActivationConfigProperty(propertyName = "maxSession", propertyValue = "3") })
>   public class ExampleEJB3MDB implements MessageListener {
>   	private static final Logger logger = Logger.getLogger(ExampleEJB3MDB.class);
>   
>   	@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
>   	public void onMessage(Message m) {
>   		logger.info("message received, waiting for 10 mins...");
>   
>   		try {
>   			Thread.sleep(600000); // 10 mins
>   
>   		} catch (InterruptedException e) {
>   		}
>   
>   		logger.info("finished waiting");
>   	}
>   }
> When a message is sent to "queue/A" and the MDB picks it up it prints "message received, waiting for 10 mins..." in the log.  After 5 minutes (300 seconds) the message appears in the log again because the transaction has timed-out and the message has been redelivered.
> I believe the problem lies in org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory in the isDeliveryTransacted method.  Here is that method [1]:
>   public boolean isDeliveryTransacted(Method method) throws NoSuchMethodException
>      {
>         TransactionManagementType mtype = TxUtil.getTransactionManagementType(container);
>         if (mtype == javax.ejb.TransactionManagementType.BEAN) return false;
>   
>   
>         TransactionAttribute attr = (TransactionAttribute)container.resolveAnnotation(method, TransactionAttribute.class);
>         if (attr == null)
>         {
>            attr =(TransactionAttribute)container.resolveAnnotation(TransactionAttribute.class);
>         }
>         TransactionAttributeType type = TransactionAttributeType.REQUIRED;
>         if (attr != null) type = attr.value();
>         return type == javax.ejb.TransactionAttributeType.REQUIRED;
>      }
> It seems there should be an explicit check for TransactionAttributeType.NOT_SUPPORTED.  If the MDB uses @TransactionManagement(TransactionManagementType.BEAN) then the redelivery doesn't occur (since the code explicitly checks this attribute and returns false if it is present).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 13:28:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 3 Jun 2009 13:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1843) All SFSB Cache
 implementations return -1 for getAvailableCount
Message-ID: <30033959.1244050136541.JavaMail.jira@cloud.prod.atl2.jboss.com>

All SFSB Cache implementations return -1 for getAvailableCount
--------------------------------------------------------------

                 Key: EJBTHREE-1843
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1843
             Project: EJB 3.0
          Issue Type: Bug
          Components: core
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.1.7, EAP 5


SFSB Metrics getAvailableCount, powered by inquiring upon the caches, always return -1.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 13:30:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 3 Jun 2009 13:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1843) All SFSB Cache
 implementations return -1 for getAvailableCount
In-Reply-To: <30033959.1244050136541.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8204388.1244050256762.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1843.
-------------------------------------------

    Resolution: Done


> All SFSB Cache implementations return -1 for getAvailableCount
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-1843
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1843
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.7, EAP 5
>
>
> SFSB Metrics getAvailableCount, powered by inquiring upon the caches, always return -1.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 14:34:07 2009
From: jira-events at lists.jboss.org (Mattias Neuling (JIRA))
Date: Wed, 3 Jun 2009 14:34:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSER-115) Exception while
 deserialization
 of java.math.BigInteger in Sun JRE 1.6.0_14 if serialized using a previous
 version e.g. JRE 1.6.0_13.
Message-ID: <21017092.1244054047588.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exception while deserialization of java.math.BigInteger in Sun JRE 1.6.0_14 if serialized using a previous version e.g. JRE 1.6.0_13. 
--------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBSER-115
                 URL: https://jira.jboss.org/jira/browse/JBSER-115
             Project: JBoss Serialization
          Issue Type: Bug
    Affects Versions: 1.0.3 GA
         Environment: Deserializing client:
- OS: Windows XP SP3 (32Bit)
- JRE 1.6.0_14

Serializing Server:
- OS: Linux Suse Enterprise (64 Bit)
- JDK 1.6.0_13 (64 Bit)
            Reporter: Mattias Neuling
            Assignee: Clebert Suconic


Failure while deserilizing java.math.BigInteger in java.math.BigDecimal on client side:
Stacktrace:
 java.io.IOException: Current classpath has lesser fields on java.math.BigInteger than its original version
	at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:98)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:381)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
	at org.jboss.serial.persister.ObjectInputStreamProxy.defaultReadObject(ObjectInputStreamProxy.java:78)
	at java.math.BigDecimal.readObject(Unknown Source)
	... 42 more


In JDK 1.6.0_14 java.math.BigInteger has one field more than in previous versions. Serialization without JBoss Serialization is no problem since it implements the methods #readObject() and #writeObject().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 15:05:57 2009
From: jira-events at lists.jboss.org (Guillaume Jeudy (JIRA))
Date: Wed, 3 Jun 2009 15:05:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1374) DLQ
 override depends on the queues definition order.
In-Reply-To: <24976851.1213606723479.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29433851.1244055957072.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470472#action_12470472 ] 

Guillaume Jeudy commented on JBMESSAGING-1374:
----------------------------------------------

Is that fix supposed to work with a durable subscription? I have a durable subscriber MDB to the topic defined below (in the correct order).  It seems as though the DLQ configuration is completely ignored and the messages are routed to the default DLQ. I'm using jboss messaging 1.4.4.GA.

<mbean code="org.jboss.jms.server.destination.QueueService"
      name="jboss.messaging.destination:service=Queue,name=msdmiTopicDLQ"
      xmbean-dd="xmdesc/Queue-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
      <attribute name="JNDIName">BOSS/DLQ/AuditServices/Events/Sharepoint</attribute>
   </mbean>   

   <mbean code="org.jboss.jms.server.destination.TopicService"
      name="jboss.messaging.destination:service=Topic,name=msdmiTopic"
      xmbean-dd="xmdesc/Topic-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
      <attribute name="JNDIName">BOSS/AuditServices/Events/Sharepoint</attribute>
      <attribute name="DLQ">jboss.messaging.destination:service=Queue,name=msdmiTopicDLQ</attribute>
   </mbean>

> DLQ override depends on the queues definition order.
> ----------------------------------------------------
>
>                 Key: JBMESSAGING-1374
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1374
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Howard Gao
>             Fix For:  1.4.0.SP3.CP04, 1.4.1.GA, 1.4.2.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 15:37:56 2009
From: jira-events at lists.jboss.org (Guillaume Jeudy (JIRA))
Date: Wed, 3 Jun 2009 15:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1374) DLQ
 override depends on the queues definition order.
In-Reply-To: <24976851.1213606723479.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9851196.1244057876835.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470474#action_12470474 ] 

Guillaume Jeudy commented on JBMESSAGING-1374:
----------------------------------------------

I stumbled upon this case: https://64.74.196.157/jira/browse/JBPAPP-871. Apparently my MDB had DLQMaxSent set to 2 so the MDB DLQ policy took precedence over JBM DLQ policy...

> DLQ override depends on the queues definition order.
> ----------------------------------------------------
>
>                 Key: JBMESSAGING-1374
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1374
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Howard Gao
>             Fix For:  1.4.0.SP3.CP04, 1.4.1.GA, 1.4.2.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 16:09:56 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Wed, 3 Jun 2009 16:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-84) WS-Trust: SAML Token
	Profile
In-Reply-To: <22333787.1240932058813.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7844228.1244059796996.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen closed JBID-84.
------------------------------

    Resolution: Done


The JBossSTS now has a SAML20TokenProvider that handles WS-Trust SAML requests.

> WS-Trust: SAML Token Profile
> ----------------------------
>
>                 Key: JBID-84
>                 URL: https://jira.jboss.org/jira/browse/JBID-84
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha2
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.beta1
>
>
> SOA-692 has requirements.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 16:09:56 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Wed, 3 Jun 2009 16:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-124) Implement WS-T SAML
 Token Profile:: SAMLV2.0 validation
In-Reply-To: <26312958.1243987260389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9839429.1244059796790.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen closed JBID-124.
-------------------------------

    Resolution: Done


SAMLV2.0 assertion validation has been implemented in the SAML20TokenProvider class.

> Implement WS-T SAML Token Profile:: SAMLV2.0 validation
> -------------------------------------------------------
>
>                 Key: JBID-124
>                 URL: https://jira.jboss.org/jira/browse/JBID-124
>             Project: JBoss Identity
>          Issue Type: Sub-task
>          Components: Identity-Federation
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha3
>
>
> The SAML token provider must be able to validate the assertions it generates. This involves validating the digital signature and also the assertion validity period (lifetime).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 17:36:56 2009
From: jira-events at lists.jboss.org (Graham Gear (JIRA))
Date: Wed, 3 Jun 2009 17:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2103)
 Knowledge*/ChangeSet APIs to
 be extended to support BRL, DSLR and DroolsCompilerAntTask compiled rules
Message-ID: <25039788.1244065016626.JavaMail.jira@cloud.prod.atl2.jboss.com>

Knowledge*/ChangeSet APIs to be extended to support BRL, DSLR and DroolsCompilerAntTask compiled rules
------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2103
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2103
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-api, drools-compiler, drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Graham Gear
            Assignee: Mark Proctor


I would like to see the new Knowledge*/ChangeSet API's to be extended to support all rule types, including BRL, DSLR and DroolsCompilerAntTask compiled rules

Although the primary compilation mechanism for BRL and DSLR  types of rules will likely be Guvnor, for completeness and an aid for developer driven rules, debug and automation I would like to see the API filled out.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 17:48:56 2009
From: jira-events at lists.jboss.org (Graham Gear (JIRA))
Date: Wed, 3 Jun 2009 17:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2104)
 KnowledgeAgentImpl cannot
 build Resources with paramatereised ResourceConfiguration's
Message-ID: <2223936.1244065736508.JavaMail.jira@cloud.prod.atl2.jboss.com>

KnowledgeAgentImpl cannot build Resources with paramatereised ResourceConfiguration's
-------------------------------------------------------------------------------------

                 Key: JBRULES-2104
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2104
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Graham Gear
            Assignee: Mark Proctor


The KnowledgeAgentImpl does not pass through ResourceConfiguration's through to KnowledgeBuilderImpl, making the building of configuration parametrised Resources not possible. Eg, trying to compile a DecisionTable (XLS) results in a NPE:

Caused by: java.lang.NullPointerException
	at org.drools.decisiontable.DecisionTableProviderImpl.compileStream(DecisionTableProviderImpl.java:26)
	at org.drools.decisiontable.DecisionTableProviderImpl.loadFromInputStream(DecisionTableProviderImpl.java:19)
	at org.drools.compiler.DecisionTableFactory.loadFromInputStream(DecisionTableFactory.java:16)
	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:508)
	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:25)
	at org.drools.agent.impl.KnowledgeAgentImpl.rebuildResources(KnowledgeAgentImpl.java:385)
	at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:119)
	at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:108)
	at com.jboss.brms.poc.KnowledgeBaseManager.loadChangeSet(KnowledgeBaseManager.java:78)
	at com.jboss.brms.poc.test.rule.DecisionTableBRLClassPathRuleTest.<clinit>(DecisionTableBRLClassPathRuleTest.java:18)
	... 17 more

In general it would be good if the KnowledgeAgent would behave exactly as the KnowledgeBuilder under the same ChangeSet configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 17:48:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 3 Jun 2009 17:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2105) For literal
 constraints on
 BitDecimal and BigIntegers, avoid coercing the literal every constraint
 check
Message-ID: <612131.1244065736734.JavaMail.jira@cloud.prod.atl2.jboss.com>

For literal constraints on BitDecimal and BigIntegers, avoid coercing the literal every constraint check
--------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2105
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2105
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


Cache it instead.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 17:50:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 3 Jun 2009 17:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2105) For literal
 constraints on
 BitDecimal and BigIntegers, avoid coercing the literal every constraint
 check
In-Reply-To: <612131.1244065736734.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20832912.1244065856720.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2105.
----------------------------------

    Resolution: Done


Fixed. Thanks for reporting.

> For literal constraints on BitDecimal and BigIntegers, avoid coercing the literal every constraint check
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2105
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2105
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> Cache it instead.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 17:50:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 3 Jun 2009 17:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2105) For literal
 constraints on
 BitDecimal and BigIntegers, avoid coercing the literal every constraint
 check
In-Reply-To: <612131.1244065736734.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4222879.1244065856843.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470510#action_12470510 ] 

Edson Tirelli commented on JBRULES-2105:
----------------------------------------

committed to revision #26819 in trunk.

> For literal constraints on BitDecimal and BigIntegers, avoid coercing the literal every constraint check
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2105
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2105
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> Cache it instead.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 18:22:56 2009
From: jira-events at lists.jboss.org (wallace njoroge (JIRA))
Date: Wed, 3 Jun 2009 18:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7000) issues when starting
 jboss server using Linux centos 5.3
Message-ID: <6401897.1244067776524.JavaMail.jira@cloud.prod.atl2.jboss.com>

issues when starting jboss server using Linux centos 5.3
--------------------------------------------------------

                 Key: JBAS-7000
                 URL: https://jira.jboss.org/jira/browse/JBAS-7000
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMX/Web Console
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: wallace njoroge
            Assignee: Darran Lofthouse


Environment:

Centos 5.3  running in VM
Linux  2.6.18-128.1.10.el5 #1 i686 i686 i386 GNU/Linux

java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)


Steps.
1. $ pwd
/usr/local/jboss/bin

2. run.sh 



pdadmin at PDPERFAppLnx01 bin]$ ./run.sh
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /usr/local/jboss
  JAVA: /home/centosadmin/jdk1.6.0_13/bin/java

  JAVA_OPTS: -Dprogram.name=run.sh -server -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true

  CLASSPATH: /usr/local/jboss/bin/run.jar:/home/centosadmin/jdk1.6.0_13/lib/tools.jar

=========================================================================

15:14:42,090 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
15:14:42,091 INFO  [ServerImpl] Release ID: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)
15:14:42,092 INFO  [ServerImpl] Bootstrap URL: null
15:14:42,092 INFO  [ServerImpl] Home Dir: /usr/local/jboss
15:14:42,092 INFO  [ServerImpl] Home URL: file:/usr/local/jboss/
15:14:42,092 INFO  [ServerImpl] Library URL: file:/usr/local/jboss/lib/
15:14:42,093 INFO  [ServerImpl] Patch URL: null
15:14:42,093 INFO  [ServerImpl] Common Base URL: file:/usr/local/jboss/common/
15:14:42,094 INFO  [ServerImpl] Common Library URL: file:/usr/local/jboss/common/lib/
15:14:42,094 INFO  [ServerImpl] Server Name: default
15:14:42,094 INFO  [ServerImpl] Server Base Dir: /usr/local/jboss/server
15:14:42,094 INFO  [ServerImpl] Server Base URL: file:/usr/local/jboss/server/
15:14:42,095 INFO  [ServerImpl] Server Config URL: file:/usr/local/jboss/server/default/conf/
15:14:42,095 INFO  [ServerImpl] Server Home Dir: /usr/local/jboss/server/default
15:14:42,095 INFO  [ServerImpl] Server Home URL: file:/usr/local/jboss/server/default/
15:14:42,095 INFO  [ServerImpl] Server Data Dir: /usr/local/jboss/server/default/data
15:14:42,096 INFO  [ServerImpl] Server Library URL: file:/usr/local/jboss/server/default/lib/
15:14:42,096 INFO  [ServerImpl] Server Log Dir: /usr/local/jboss/server/default/log
15:14:42,096 INFO  [ServerImpl] Server Native Dir: /usr/local/jboss/server/default/tmp/native
15:14:42,096 INFO  [ServerImpl] Server Temp Dir: /usr/local/jboss/server/default/tmp
15:14:42,097 INFO  [ServerImpl] Server Temp Deploy Dir: /usr/local/jboss/server/default/tmp/deploy
15:14:42,975 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/usr/local/jboss/server/default/conf/bootstrap.xml
15:14:43,586 INFO  [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.plugins.cache.CombinedVFSCache]
15:14:43,589 INFO  [VFSCacheFactory] Using VFSCache [CombinedVFSCache[real-cache: null]]
15:14:43,940 INFO  [CopyMechanism] VFS temp dir: /usr/local/jboss/server/default/tmp
15:14:43,941 INFO  [ZipEntryContext] VFS force nested jars copy-mode is enabled.
15:14:45,822 INFO  [ServerInfo] Java version: 1.6.0_13,Sun Microsystems Inc.
15:14:45,822 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
15:14:45,823 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Server VM 11.3-b02,Sun Microsystems Inc.
15:14:45,823 INFO  [ServerInfo] OS-System: Linux 2.6.18-128.1.10.el5,i386
15:14:45,824 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/usr/local/jboss/lib/endorsed
15:14:45,905 INFO  [JMXKernel] Legacy JMX core initialized
15:14:49,308 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 487fb7[domain=default, server=default, name=default]
15:14:50,731 ERROR [AbstractKernelController] Error installing to Parse: name=vfsfile:/usr/local/jboss/server/default/conf/jboss-service.xml state=Not Installed mode=Manual requiredState=Parse
org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfsfile:/usr/local/jboss/server/default/conf/jboss-service.xml
        at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
        at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:362)
        at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:322)
        at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:294)
        at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.deploy(AbstractParsingDeployerWithOutput.java:234)
        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.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.jbos



Expected.
Should work


Error:
Error creating managed object for vfsfile:/usr/local/jboss/server/default/conf/jboss-service.xml

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 19:29:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 3 Jun 2009 19:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2106) Allow "implicit"
 operators in the language
Message-ID: <13932462.1244071796460.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow "implicit" operators in the language
------------------------------------------

                 Key: JBRULES-2106
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2106
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


It would be cool if we could develop and enable "implicit" operators. By that I mean, a method that returns a boolean and take 1 parameter could be used automatically. Example:

Person( name startsWith "Edson" )

The engine would understand the "startsWith" implicit operator, and would call the method on the name String.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 19:42:09 2009
From: jira-events at lists.jboss.org (Mauricio Salatino (JIRA))
Date: Wed, 3 Jun 2009 19:42:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2107) Support StateNode
 for Finite State Machines
Message-ID: <19207617.1244072529147.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support StateNode for Finite State Machines
-------------------------------------------

                 Key: JBRULES-2107
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2107
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler (flow), drools-core (flow)
    Affects Versions: 5.1.0.M1
            Reporter: Mauricio Salatino
            Assignee: Mauricio Salatino


Support for StateNode for Finite State Machines

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 22:13:56 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 3 Jun 2009 22:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-288) Errors show up in
	problems view
In-Reply-To: <13325945.1231384923985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29218660.1244081636386.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-288:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.GA
                       (was: jBPM jPDL Designer 4.0.0.CR1)


some work still needs to be done, slip to GA release

> Errors show up in problems view
> -------------------------------
>
>                 Key: GPD-288
>                 URL: https://jira.jboss.org/jira/browse/GPD-288
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>            Priority: Critical
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Process errors (e.g. duplicate node names) should show up in the problems view and should have the 'problem' annotation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 22:16:08 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 3 Jun 2009 22:16:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-331) Support HQL attributes
	and elements
In-Reply-To: <143992.1241701546509.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20229445.1244081768273.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-331:
--------------------------


slip to GA release

> Support HQL attributes and elements
> -----------------------------------
>
>                 Key: GPD-331
>                 URL: https://jira.jboss.org/jira/browse/GPD-331
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> attributes: var, unique
> elements: query, parameter

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 22:16:08 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 3 Jun 2009 22:16:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-331) Support HQL attributes
	and elements
In-Reply-To: <143992.1241701546509.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23790358.1244081768383.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-331:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.GA
                       (was: jBPM jPDL Designer 4.0.0.CR1)


> Support HQL attributes and elements
> -----------------------------------
>
>                 Key: GPD-331
>                 URL: https://jira.jboss.org/jira/browse/GPD-331
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> attributes: var, unique
> elements: query, parameter

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 22:16:08 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 3 Jun 2009 22:16:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-335) add proper licence
	text
In-Reply-To: <6494146.1242893636570.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4025578.1244081768172.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-335.
---------------------------

    Resolution: Done


EPL license is contained in all the features

> add proper licence text
> -----------------------
>
>                 Key: GPD-335
>                 URL: https://jira.jboss.org/jira/browse/GPD-335
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.CR1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 22:17:56 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 3 Jun 2009 22:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-341) renaming swimlane
 should make editor dirty
In-Reply-To: <31349923.1243352997231.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23216847.1244081876375.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-341:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.GA
                       (was: jBPM jPDL Designer 4.0.0.CR1)


slip to GA release

> renaming swimlane should make editor dirty
> ------------------------------------------
>
>                 Key: GPD-341
>                 URL: https://jira.jboss.org/jira/browse/GPD-341
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun  3 23:12:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 3 Jun 2009 23:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-126) IDPWebBrowserSSOValve
 needs work to send the error response properly
Message-ID: <4282669.1244085176426.JavaMail.jira@cloud.prod.atl2.jboss.com>

IDPWebBrowserSSOValve needs work to send the error response properly 
---------------------------------------------------------------------

                 Key: JBID-126
                 URL: https://jira.jboss.org/jira/browse/JBID-126
             Project: JBoss Identity
          Issue Type: Bug
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


When there are exceptions such as IssuerNoTrustedException, the IDP should send a proper saml response.  For this, the valve needs to preprocess the saml request and determine the assertion consumer url.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 00:14:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 4 Jun 2009 00:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-198) Default namespace
	for connector
In-Reply-To: <31227187.1242149206811.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3254849.1244088896621.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBMETA-198.
-------------------------------

    Fix Version/s: 1.0.2.Beta1
       Resolution: Done


> Default namespace for connector
> -------------------------------
>
>                 Key: JBMETA-198
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-198
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Zhang
>             Fix For: 1.0.2.Beta1
>
>
> If the user doesn't specify a namespace in the ra.xml - like
>  <connector>
> and there isn't a DTD definition either we should map that namespace to JCA15MetaData.
> That would allow the RA deployer to continue to parse the file and log a WARN to the user.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 00:17:08 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 4 Jun 2009 00:17:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-199) Default namespace
	for jboss-ra
In-Reply-To: <1877135.1242149339350.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27831789.1244089028420.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBMETA-199.
-------------------------------

    Fix Version/s: 1.0.2.Beta1
       Resolution: Done


> Default namespace for jboss-ra
> ------------------------------
>
>                 Key: JBMETA-199
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-199
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Zhang
>             Fix For: 1.0.2.Beta1
>
>
> If the user doesn't specify a namespace in the jboss-ra.xml - like
>  <jboss-ra>
> and there isn't a DTD definition either we should map that namespace to JBossRAMetaData.
> That would allow the RA deployer to continue to parse the file and log a WARN to the user.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 01:37:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 4 Jun 2009 01:37:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1637) Interruption
	is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24447070.1244093878006.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1637:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09


> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 01:41:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 4 Jun 2009 01:41:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1637)
	Interruption is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12074069.1244094117230.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470540#action_12470540 ] 

Howard Gao commented on JBMESSAGING-1637:
-----------------------------------------

Hi David, Thanks for explanation.


> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 03:32:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 4 Jun 2009 03:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-947) Messages that are
 bundled but
 are over max_bundle_size are silently dropped on the floor.
In-Reply-To: <7003516.1238675182543.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17198625.1244100776703.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470547#action_12470547 ] 

Bela Ban commented on JGRP-947:
-------------------------------

NAKACK actually doesn't use OOB anymore, so retransmitted messages *are* bundled. This means that every retransmission causes this stack trace.

Propagating the exception all the way up to the caller is not a good idea IMO, because the caller might re-send the buffer and then we even compound the issue.

I guess we need to catch this misconfiguration issue at stack start time, ie. throw an exception if FRAG2.frag_size > TP.max_bundle_size (if bundling is enabled)

> Messages that are bundled but are over max_bundle_size are silently dropped on the floor.
> -----------------------------------------------------------------------------------------
>
>                 Key: JGRP-947
>                 URL: https://jira.jboss.org/jira/browse/JGRP-947
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: JGroups version 2.7.0
>            Reporter: Hunter Kelly
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> in TP.java, at line 1562, an error is thrown if a packet is too big.  However, this exception is caught in TP.java at line 913.  It is logged, but in my opinion this error should be propagated all the way up the call stack.
> This causes particularly confusing behavior when NACKACK is in the stack, because the next time a message that is sent that is small enough, any and all receivers will ask for a re-transmit of this message from the sender, and the default code path will then _not_ go through the bundler, so the packet will then be successfully sent.
> This means that you get a dire looking log message but code that still works, but (potentially) much more inefficiantly.
> IMHO, errors like this should be propagated back up to the offending code, so that the error can be detected and corrected.
> It also makes it virtually impossible to write test code that tests behaviour of different JGroups configurations.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 03:39:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 4 Jun 2009 03:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-947) Messages that are
 bundled but are
 over max_bundle_size are silently dropped on the floor.
In-Reply-To: <7003516.1238675182543.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5736080.1244101196704.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-947.
---------------------------

    Resolution: Done


I added a check to FRAG2 which makes sure frag_size < TP.max_bundle_size (if bundling is enabled)

> Messages that are bundled but are over max_bundle_size are silently dropped on the floor.
> -----------------------------------------------------------------------------------------
>
>                 Key: JGRP-947
>                 URL: https://jira.jboss.org/jira/browse/JGRP-947
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: JGroups version 2.7.0
>            Reporter: Hunter Kelly
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> in TP.java, at line 1562, an error is thrown if a packet is too big.  However, this exception is caught in TP.java at line 913.  It is logged, but in my opinion this error should be propagated all the way up the call stack.
> This causes particularly confusing behavior when NACKACK is in the stack, because the next time a message that is sent that is small enough, any and all receivers will ask for a re-transmit of this message from the sender, and the default code path will then _not_ go through the bundler, so the packet will then be successfully sent.
> This means that you get a dire looking log message but code that still works, but (potentially) much more inefficiantly.
> IMHO, errors like this should be propagated back up to the offending code, so that the error can be detected and corrected.
> It also makes it virtually impossible to write test code that tests behaviour of different JGroups configurations.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 03:56:09 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 4 Jun 2009 03:56:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-967) Deadlock in FD_SOCK
In-Reply-To: <31434384.1240948306486.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8212586.1244102170427.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-967:
--------------------------

    Fix Version/s: 2.4.7
                       (was: 2.8)


Moved to 2.4.7

> Deadlock in FD_SOCK 
> --------------------
>
>                 Key: JGRP-967
>                 URL: https://jira.jboss.org/jira/browse/JGRP-967
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.5
>         Environment: Deadlock detected on Fedora 8, JDK 1.4/JDK 1.5.
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.4.7
>
>         Attachments: example0.png, example1.png, threadDump.FD_SOCK.txt
>
>
> Due to a problem with IPv6 addresses and ServerSocket connections hanging, a deadlock was revealed in FD_SOCK. 
> The deadlock reveals itself, for example, in the test RpcDispatcherAnycastTest at the end of the test, when the channels are being torn down. What follows are my original emails to Bela:
> Richard: 
> I've tracked down the test case failure of RpcDispatcherAnycastTest under IPv6 to a problem with shutting down the protocol stack. The test executes fine, but in the teardown phase, when the test tries to close the three JChannels which have been set up, the first channel closes correctly, but the second channel hangs.
> JChannel tries to disconnect from the group before shutting down by:
> (i) sending a DISCONNECT event and waits for a DISCONNECT_OK event via a promise
> (ii) sending a STOP_QUEUING event and waita for a return from the call (i.e. has reached the bottom of the stack)
> It then calls ProtocolStack.stopStack() which sends a STOP event down the stack and waits for a STOP_OK event via a promise.
> The STOP event is not making its way correctly down the stack.
> Here is a trace with IPv4 (i've added in some tracing of the STOP event of my own):
>    [junit] JChannel.disconnect(): waiting for DISCONNECT_OK
>    [junit] JChannel.disconnect(): got DISCONNECT_OK
>    [junit] JChannel.disconnect(): stopping queue
>    [junit] FD_SOCK.down called, event = STOP_QUEUEING
>    [junit] JChannel.disconnect(): stopped queue
>    [junit] JChannel.disconnect(): stopping stack
>    [junit] ProtocolStack: Sending STOP event
>    [junit] STATE_TRANSFER: STOP event received
>    [junit] FRAG2: STOP event received
>    [junit] FC: STOP event received
>    [junit] GMS: STOP event received
>    [junit] VIEW_SYNC: STOP event received
>    [junit] pbcast.STABLE: STOP event received
>    [junit] UNICAST: STOP event received
>    [junit] VERIFY_SUSPECT: STOP event received
>    [junit] FD: STOP event received
>    [junit] FD_SOCK.down called, event = STOP
>    [junit] FD_SOCK: STOP event received
>    [junit] MERGE2: STOP event received
>    [junit] PING: STOP event received
>    [junit] ProtocolStack: Received STOP event
>    [junit] JChannel.disconnect(): stopped stack
> Here is a bad trace with IPv6:
>    [junit] JChannel.disconnect(): waiting for DISCONNECT_OK
>    [junit] JChannel.disconnect(): got DISCONNECT_OK
>    [junit] JChannel.disconnect(): stopping queue
>    [junit] FD_SOCK.down called, event = STOP_QUEUEING
>    [junit] JChannel.disconnect(): stopped queue
>    [junit] JChannel.disconnect(): stopping stack
>    [junit] ProtocolStack: Sending STOP event
>    [junit] STATE_TRANSFER: STOP event received
>    [junit] FRAG2: STOP event received
>    [junit] FC: STOP event received
>    [junit] GMS: STOP event received
>    [junit] VIEW_SYNC: STOP event received
>    [junit] pbcast.STABLE: STOP event received
>    [junit] UNICAST: STOP event received
>    [junit] VERIFY_SUSPECT: STOP event received
>    [junit] FD: STOP event received
>    [junit] FD_SOCK.down called, event = MSG
>    [junit] FD_SOCK.down called, event = MSG
>    [junit] FD_SOCK.down called, event = MSG
>    [junit] FD_SOCK.down called, event = MSG
> If I remove FD_SOCK from the stack, the tests pass. If I include it, this stuff happens.
> I also found that if I turn on the uphandler and downhandler threads in FD_SOCK, the problem disappears:
> ...
>    <MERGE2 max_interval="30000" down_thread="false" up_thread="false" min_interval="10000"/>
>    <FD_SOCK down_thread="true" up_thread="true"/>    <FD timeout="10000" max_tries="5" down_thread="false" up_thread="false" shun="true"/>
> ...
> Bela:
> Then it must be a locking issue, I'll take a look tomorrow. Or if you find the solution sooner, all the better !  :-)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 03:59:41 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 4 Jun 2009 03:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6981) AttachmentStore MC
 bean
 (org.jboss.system.server.profileservice.repository.AbstractAttachmentStore)
 configuration does not specify the parameter type for constructor
In-Reply-To: <13505017.1243427639041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5044430.1244102382164.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved JBAS-6981.
---------------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Resolution: Done


> AttachmentStore MC bean (org.jboss.system.server.profileservice.repository.AbstractAttachmentStore) configuration does not specify the parameter type for constructor
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6981
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6981
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The profile.xml has this configuration for AttachmentStore:
> 	<bean name="AttachmentStore" class="org.jboss.system.server.profileservice.repository.AbstractAttachmentStore">
> 		<constructor><parameter><inject bean="BootstrapProfileFactory" property="attachmentStoreRoot" /></parameter></constructor>
> ....
> However, there are multiple constructors available for org.jboss.system.server.profileservice.repository.AbstractAttachmentStore. MC randomly picks up one of the available constructors and this can lead to exceptions as noted in the referenced forum thread.
> The fix is to provide the parameter type for the constructor in the MC bean configuration (note the use of class="java,io.File" for the constructor parameter):
> <bean name="AttachmentStore" class="org.jboss.system.server.profileservice.repository.AbstractAttachmentStore">
> 		<constructor><parameter class="java.io.File"><inject bean="BootstrapProfileFactory" property="attachmentStoreRoot" /></parameter></constructor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 04:02:03 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 4 Jun 2009 04:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6693) Add deployExploded
 argument to DeploymentManager.distribute()
In-Reply-To: <22761801.1238177902939.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14763648.1244102523743.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved JBAS-6693.
---------------------------------------

    Resolution: Done


As mentioned on the forums, i've added some DeploymentOptions to enable this. The usage would be something like:

getDeploymentManager().distribute(deployment, deploymentURL, new DeploymentOption[] { DeploymentOption.Explode });

> Add deployExploded argument to DeploymentManager.distribute()
> -------------------------------------------------------------
>
>                 Key: JBAS-6693
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6693
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Charles Crouch
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> It would be helpful if we could tell the DeploymentManager to expand the archive when its deployed, since linked issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 04:03:57 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 4 Jun 2009 04:03:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6758) Entering Global
 JNDI name in
 embedded console for new ConnectionFactory results in FileNotFoundException
In-Reply-To: <28783847.1239229102427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32983321.1244102637130.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved JBAS-6758.
---------------------------------------

    Resolution: Done


This should be fixed as well.

> Entering Global JNDI name in embedded console for new ConnectionFactory results in FileNotFoundException
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6758
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6758
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Shelly McGowan
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When entering a Global JNDI name using
> eis/ejb_Deployment, an attempt to create the new resource results in the following Exception.  Using ejb_Deployment only is successful.
> Failed to add Resource (see app server log for additional details): java.lang.RuntimeException:Failed to process template. -> java.lang.RuntimeException:java.io.FileNotFoundException: /TEST/Branch_5_x/build/output/jboss-5.1.0.CR1/server/all/deploy/eis/ejb_Deployment-ds.xml (No such file or directory) -> java.io.FileNotFoundException:/TEST/Branch_5_x/build/output/jboss-5.1.0.CR1/server/all/deploy/eis/ejb_Deployment-ds.xml (No such file or directory) 
> Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: /TEST/Branch_5_x/build/output/jboss-5.1.0.CR1/server/all/deploy/eis/ejb_Deployment_whitebox-tx.rar-ds.xml (No such file or directory)
>         at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.transferDeployment(StreamingDeploymentTarget.java:287)
>         at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.distribute(StreamingDeploymentTarget.java:107)
>         at org.jboss.profileservice.management.upload.DeploymentProgressImpl.distribute(DeploymentProgressImpl.java:177)
>         at org.jboss.profileservice.management.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:82)
>         at org.jboss.profileservice.management.AbstractTemplateCreator.distribute(AbstractTemplateCreator.java:158)
>         at org.jboss.profileservice.management.AbstractTemplateCreator.applyTemplate(AbstractTemplateCreator.java:99)
>         at org.jboss.profileservice.management.ManagementViewImpl.applyTemplate(ManagementViewImpl.java:1005)
> <snip>
> Caused by: java.io.FileNotFoundException: /TEST/Branch_5_x/build/output/jboss-5.1.0.CR1/server/all/deploy/eis/ejb_Deployment_whitebox-tx.rar-ds.xml (No such file or directory)
>         at java.io.FileOutputStream.open(Native Method)
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
>         at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.addDeploymentContent(BasicDeploymentRepository.java:147)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 04:53:56 2009
From: jira-events at lists.jboss.org (Dmitri Voronov (JIRA))
Date: Thu, 4 Jun 2009 04:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBJCA-94) Reauthentication
	support
In-Reply-To: <11499795.1242049679393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1870009.1244105636795.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBJCA-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470559#action_12470559 ] 

Dmitri Voronov commented on JBJCA-94:
-------------------------------------

Since JCA specification addresses reauthentication responsibilities to both server and resource adapter, its implementation can be considered separately. In my opinion there should be two different tasks:
First of all the JBoss JCA has to provide reauthentication support, if a certain resource adapter; and it could be a third party resource adapter, does support. The JBoss JCA has to recognize this ability by interpreting of the ra.xml and provide an appropriate pooling and handling for Managed Connections.
The second task is to implement reauthentication in JBoss own resource adapters like JDBC.

>From my point of view the first task is most important, since the third party resource adapter depend on this feature. This will help to avoid such scenarios mentioned in the forum topic. I assume that an implementation of this feature in JBoss JCA is not so difficult.

> Reauthentication support
> ------------------------
>
>                 Key: JBJCA-94
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-94
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Core
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>
> Implement reauthentication support.
> See chapter 8 and related security discussions for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 05:18:59 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 4 Jun 2009 05:18:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-205) element name
 shouldn't be assigned to schemaLocation if namespace is not null
Message-ID: <17084352.1244107139708.JavaMail.jira@cloud.prod.atl2.jboss.com>

element name shouldn't be assigned to schemaLocation if namespace is not null
-----------------------------------------------------------------------------

                 Key: JBXB-205
                 URL: https://jira.jboss.org/jira/browse/JBXB-205
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.1.GA
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossXB-2.0.2.GA


In SundayContentHandler before schema resolution if schemaLocation was not provided in XML and DTD systemId is not available, schemaLocation is assigned to the localName of the element. This is useful for XML files that are validated against DTDs (or don't use a specific namespace). But if the namespace is not null there comes a problem since non-null schema location will override the one used in JBossEntityResolver (making mapping of nsURI to schemaLocation in the resolver useless).
So, assigning schemaLocation to localName should be done only for schemas that don't use namespaces.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 05:22:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 4 Jun 2009 05:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-205) element name shouldn't
 be assigned to schemaLocation if namespace is not null
In-Reply-To: <17084352.1244107139708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14470541.1244107376687.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBXB-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBXB-205.
----------------------------------

    Resolution: Done


Done.

> element name shouldn't be assigned to schemaLocation if namespace is not null
> -----------------------------------------------------------------------------
>
>                 Key: JBXB-205
>                 URL: https://jira.jboss.org/jira/browse/JBXB-205
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> In SundayContentHandler before schema resolution if schemaLocation was not provided in XML and DTD systemId is not available, schemaLocation is assigned to the localName of the element. This is useful for XML files that are validated against DTDs (or don't use a specific namespace). But if the namespace is not null there comes a problem since non-null schema location will override the one used in JBossEntityResolver (making mapping of nsURI to schemaLocation in the resolver useless).
> So, assigning schemaLocation to localName should be done only for schemas that don't use namespaces.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 05:25:23 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 4 Jun 2009 05:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6655) Upgrade AOP to
	2.1.1.GA
In-Reply-To: <31461795.1237807222491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8690304.1244107523045.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated JBAS-6655:
-----------------------------

    Summary: Upgrade AOP to 2.1.1.GA  (was: Upgrade AOP to 2.1.0.GA)


> Upgrade AOP to 2.1.1.GA
> -----------------------
>
>                 Key: JBAS-6655
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6655
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 05:40:56 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 4 Jun 2009 05:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-6655) Upgrade AOP to
	2.1.1.GA
In-Reply-To: <31461795.1237807222491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1987510.1244108456510.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed JBAS-6655.
----------------------------

    Resolution: Done


> Upgrade AOP to 2.1.1.GA
> -----------------------
>
>                 Key: JBAS-6655
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6655
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 05:40:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 4 Jun 2009 05:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-973)
 DistributedLockManager: lock()
 should block for timeout ms until it can acquire lock
In-Reply-To: <26784780.1241588866577.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7143642.1244108456664.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-973:
--------------------------

    Fix Version/s: 3.x
                       (was: 2.8)


This requires too many changes, moved to 3.x. Maybe this feature will be provided by a complete rewrite of DLM

> DistributedLockManager: lock() should block for timeout ms until it can acquire lock
> ------------------------------------------------------------------------------------
>
>                 Key: JGRP-973
>                 URL: https://jira.jboss.org/jira/browse/JGRP-973
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.x
>
>
> Currently, lock() throw an exception *immediately* if the lock is held by someone else. It doesn't respect the timeout parameter, change this. This might be possible by picking a different VotingAdapter, have to investigate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 06:05:56 2009
From: jira-events at lists.jboss.org (Hans-Joerg Adel (JIRA))
Date: Thu, 4 Jun 2009 06:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-83)
 NullPointerException in Handler#getType
Message-ID: <2275005.1244109956457.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointerException in Handler#getType
---------------------------------------

                 Key: JASSIST-83
                 URL: https://jira.jboss.org/jira/browse/JASSIST-83
             Project: Javassist
          Issue Type: Bug
         Environment: JA version 3.4, Windows Vista and JDK 1.6.0_10
            Reporter: Hans-Joerg Adel
            Assignee: Shigeru Chiba
            Priority: Optional


Hi!

When I use ExprEditor#edit(Handler) to access a try-statement without a catch-clause I get a NullPointerException. 

To reproduce the bug, please use this source

/*--- (C) 1999-2008 Techniker Krankenkasse ---*/

package samplepackage;

import javassist.CannotCompileException;
import javassist.ClassPool;
import javassist.CtClass;
import javassist.NotFoundException;

import javassist.expr.ExprEditor;
import javassist.expr.Handler;

public class Sample {
	public static void main(String[] args) throws NotFoundException, CannotCompileException {
		ClassPool classPool = ClassPool.getDefault();
		CtClass ctClass = classPool.get("samplepackage.SampleClass");
		ctClass.instrument(new MyExprEditor());

	}

	static class MyExprEditor extends ExprEditor {
		@Override
		public void edit(Handler h) throws CannotCompileException {
			try {
				h.getType();
			} catch (NotFoundException e) {
			}
		}
	}
}



Stacktrace:
Exception in thread "main" java.lang.NullPointerException
	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:517)
	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:499)
	at javassist.expr.Handler.getType(Handler.java:76)
	at samplepackage.Sample$MyExprEditor.edit(Sample.java:25)
	at javassist.expr.ExprEditor.doit(ExprEditor.java:97)
	at javassist.CtClassType.instrument(CtClassType.java:1224)
	at samplepackage.Sample.main(Sample.java:17)

I would expect that h.getType() returns null.

I am using JA version 3.4, Windows Vista and JDK 1.6.0_10.

Cheers
Ruwen
iA Hans-Joerg Adel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 06:54:56 2009
From: jira-events at lists.jboss.org (Hans-Joerg Adel (JIRA))
Date: Thu, 4 Jun 2009 06:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-83)
 NullPointerException in Handler#getType
In-Reply-To: <2275005.1244109956457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5539798.1244112896677.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hans-Joerg Adel updated JASSIST-83:
-----------------------------------

    Attachment: SampleClass.java


Forgotten

> NullPointerException in Handler#getType
> ---------------------------------------
>
>                 Key: JASSIST-83
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-83
>             Project: Javassist
>          Issue Type: Bug
>         Environment: JA version 3.4, Windows Vista and JDK 1.6.0_10
>            Reporter: Hans-Joerg Adel
>            Assignee: Shigeru Chiba
>            Priority: Optional
>         Attachments: SampleClass.java
>
>
> Hi!
> When I use ExprEditor#edit(Handler) to access a try-statement without a catch-clause I get a NullPointerException. 
> To reproduce the bug, please use this source
> /*--- (C) 1999-2008 Techniker Krankenkasse ---*/
> package samplepackage;
> import javassist.CannotCompileException;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.NotFoundException;
> import javassist.expr.ExprEditor;
> import javassist.expr.Handler;
> public class Sample {
> 	public static void main(String[] args) throws NotFoundException, CannotCompileException {
> 		ClassPool classPool = ClassPool.getDefault();
> 		CtClass ctClass = classPool.get("samplepackage.SampleClass");
> 		ctClass.instrument(new MyExprEditor());
> 	}
> 	static class MyExprEditor extends ExprEditor {
> 		@Override
> 		public void edit(Handler h) throws CannotCompileException {
> 			try {
> 				h.getType();
> 			} catch (NotFoundException e) {
> 			}
> 		}
> 	}
> }
> Stacktrace:
> Exception in thread "main" java.lang.NullPointerException
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:517)
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:499)
> 	at javassist.expr.Handler.getType(Handler.java:76)
> 	at samplepackage.Sample$MyExprEditor.edit(Sample.java:25)
> 	at javassist.expr.ExprEditor.doit(ExprEditor.java:97)
> 	at javassist.CtClassType.instrument(CtClassType.java:1224)
> 	at samplepackage.Sample.main(Sample.java:17)
> I would expect that h.getType() returns null.
> I am using JA version 3.4, Windows Vista and JDK 1.6.0_10.
> Cheers
> Ruwen
> iA Hans-Joerg Adel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 06:56:56 2009
From: jira-events at lists.jboss.org (Hans-Joerg Adel (JIRA))
Date: Thu, 4 Jun 2009 06:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-83)
 NullPointerException in Handler#getType
In-Reply-To: <2275005.1244109956457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31443905.1244113016465.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hans-Joerg Adel updated JASSIST-83:
-----------------------------------

    Attachment: Sample.java


Completeness

> NullPointerException in Handler#getType
> ---------------------------------------
>
>                 Key: JASSIST-83
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-83
>             Project: Javassist
>          Issue Type: Bug
>         Environment: JA version 3.4, Windows Vista and JDK 1.6.0_10
>            Reporter: Hans-Joerg Adel
>            Assignee: Shigeru Chiba
>            Priority: Optional
>         Attachments: Sample.java, SampleClass.java
>
>
> Hi!
> When I use ExprEditor#edit(Handler) to access a try-statement without a catch-clause I get a NullPointerException. 
> To reproduce the bug, please use this source
> /*--- (C) 1999-2008 Techniker Krankenkasse ---*/
> package samplepackage;
> import javassist.CannotCompileException;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.NotFoundException;
> import javassist.expr.ExprEditor;
> import javassist.expr.Handler;
> public class Sample {
> 	public static void main(String[] args) throws NotFoundException, CannotCompileException {
> 		ClassPool classPool = ClassPool.getDefault();
> 		CtClass ctClass = classPool.get("samplepackage.SampleClass");
> 		ctClass.instrument(new MyExprEditor());
> 	}
> 	static class MyExprEditor extends ExprEditor {
> 		@Override
> 		public void edit(Handler h) throws CannotCompileException {
> 			try {
> 				h.getType();
> 			} catch (NotFoundException e) {
> 			}
> 		}
> 	}
> }
> Stacktrace:
> Exception in thread "main" java.lang.NullPointerException
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:517)
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:499)
> 	at javassist.expr.Handler.getType(Handler.java:76)
> 	at samplepackage.Sample$MyExprEditor.edit(Sample.java:25)
> 	at javassist.expr.ExprEditor.doit(ExprEditor.java:97)
> 	at javassist.CtClassType.instrument(CtClassType.java:1224)
> 	at samplepackage.Sample.main(Sample.java:17)
> I would expect that h.getType() returns null.
> I am using JA version 3.4, Windows Vista and JDK 1.6.0_10.
> Cheers
> Ruwen
> iA Hans-Joerg Adel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 07:37:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 4 Jun 2009 07:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1637) Interruption
	is busted
In-Reply-To: <9572662.1243893957150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17119922.1244115476521.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1637.
-----------------------------------

    Resolution: Done


done

> Interruption is busted
> ----------------------
>
>                 Key: JBMESSAGING-1637
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1637
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA, 1.4.3.GA
>            Reporter: David Lloyd
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: fix-interruption.patch
>
>
> Interruption handling is way wrong in MessagingPostOffice.  Attaching a patch that at least prevents large amounts of exception spewage when a JBM thread is interrupted.  Please check it over and apply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 07:41:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 4 Jun 2009 07:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-721) Binds with similar
 pointcut expressions are ignored
In-Reply-To: <10693694.1239946822969.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10889656.1244115716762.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAOP-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470592#action_12470592 ] 

Carlo de Wolf commented on JBAOP-721:
-------------------------------------

In another setup:
13:33:53,133 DEBUG [Aspect] Bound aspect org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor; deployed:true
13:33:55,889 DEBUG [Aspect] Bound aspect org.jboss.ejb3.test.tx.common.SessionSynchronizationInterceptor; deployed:true
13:33:58,073 DEBUG [Aspect] Bound aspect org.jboss.ejb3.test.tx.common.StatefulInstanceInterceptor; deployed:true
13:34:00,223 DEBUG [Aspect] Bound aspect org.jboss.ejb3.tx.BMTTxInterceptorFactory; deployed:true
13:34:02,989 DEBUG [Aspect] Bound aspect org.jboss.ejb3.tx.CMTTxInterceptorFactory; deployed:true
13:34:04,956 DEBUG [Aspect] Bound aspect org.jboss.ejb3.tx.RetryingInterceptor; deployed:true
13:34:07,415 DEBUG [Aspect] Bound aspect org.jboss.ejb3.test.tx.common.SynchronizationActionInterceptor; deployed:true
13:34:14,853 DEBUG [AspectBinding] Bound binding 3j001-dcvc15-fvje2q5e-1-fvje2szj-4
13:34:20,389 DEBUG [AspectBinding] Bound binding 3j001-dcvc15-fvje2q5e-1-fvje2szo-5
13:34:22,835 DEBUG [AspectBinding] Bound binding 3j001-dcvc15-fvje2q5e-1-fvje2szp-6
13:38:57,546 DEBUG [AspectBinding] Bound binding 3j001-dcvc15-fvje2q5e-1-fvje2szq-8
13:38:59,271 DEBUG [AspectBinding] Bound binding 3j001-dcvc15-fvje2q5e-1-fvje2szr-9

For some reason MC doesn't start the 7th advice binding, but since there is no check whether the deployment is complete, the reason remains unknown.

> Binds with similar pointcut expressions are ignored
> ---------------------------------------------------
>
>                 Key: JBAOP-721
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-721
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.0.GA
>         Environment: Branch_5_x @ 87425
>            Reporter: Carlo de Wolf
>            Assignee: Flavia Rainone
>            Priority: Critical
>             Fix For: 2.1.2.GA, 2.2.0.GA
>
>
> Given the following descriptor:
> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/trunk/core/src/main/resources/ejb3-interceptors-aop.xml?revision=87350&view=markup
> 04-16-2009 09:47:58:  ERROR: java.lang.NullPointerException
>     at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
>     at org.jboss.ejb3.tx.TxInterceptor$Never.invoke(TxInterceptor.java:63)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:560)
>     at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>     at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91) 
> StatefulInstanceInterceptor is not executed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 08:06:17 2009
From: jira-events at lists.jboss.org (Martin Vecera (JIRA))
Date: Thu, 4 Jun 2009 08:06:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6328) jmx-console: Back
 to MBean button causes error
In-Reply-To: <29723732.1229531464862.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12663232.1244117177940.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Vecera reassigned JBAS-6328:
-----------------------------------

    Assignee: Dimitris Andreadis  (was: Farah Juma)


Dimitris, could you please close the issue if it is verified? I found that one by chance and I don't have enough time to give it a try right now...

> jmx-console: Back to MBean button causes error
> ----------------------------------------------
>
>                 Key: JBAS-6328
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6328
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX/Web Console
>    Affects Versions: JBossAS-5.0.0.GA
>            Reporter: Martin Vecera
>            Assignee: Dimitris Andreadis
>            Priority: Critical
>             Fix For: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: ApplyChangesButton.patch, JBAS-6328.patch
>
>
> After invoking an operation in JMX Console (e.g. startDatabaseManager under http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB), the button "Back to MBean" on result page causes Error 500.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 08:22:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 4 Jun 2009 08:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-721) Binds with similar
 pointcut expressions are ignored
In-Reply-To: <10693694.1239946822969.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24153204.1244118176573.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAOP-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470601#action_12470601 ] 

Carlo de Wolf commented on JBAOP-721:
-------------------------------------

By using the regular BeanDeployer instead of AbstractAopMetaDataDeployer.deployBeans (which is bad) I get:

org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

DEPLOYMENTS MISSING DEPENDENCIES:
  Deployment "3j001-jm9okg-fvjfr10d-1-fvjfr3r7-7" is missing the following dependencies:
    Dependency "3j001-jm9okg-fvjfr10d-1-fvjfr3r7-7$2" (should be in state "Configured", but is actually in state "Instantiated")
  Deployment "3j001-jm9okg-fvjfr10d-1-fvjfr3r7-7$2" is missing the following dependencies:
    Dependency "org.jboss.ejb3.tx.test.common.SynchronizationActionInterceptor" (should be in state "Configured", but is actually in state "** NOT FOUND Depends on 'org.jboss.ejb3.tx.test.common.SynchronizationActionInterceptor' **")

DEPLOYMENTS IN ERROR:
  Deployment "org.jboss.ejb3.tx.test.common.SynchronizationActionInterceptor" is in error due to the following reason(s): ** NOT FOUND Depends on 'org.jboss.ejb3.tx.test.common.SynchronizationActionInterceptor' **


> Binds with similar pointcut expressions are ignored
> ---------------------------------------------------
>
>                 Key: JBAOP-721
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-721
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.0.GA
>         Environment: Branch_5_x @ 87425
>            Reporter: Carlo de Wolf
>            Assignee: Flavia Rainone
>            Priority: Critical
>             Fix For: 2.1.2.GA, 2.2.0.GA
>
>
> Given the following descriptor:
> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/trunk/core/src/main/resources/ejb3-interceptors-aop.xml?revision=87350&view=markup
> 04-16-2009 09:47:58:  ERROR: java.lang.NullPointerException
>     at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
>     at org.jboss.ejb3.tx.TxInterceptor$Never.invoke(TxInterceptor.java:63)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:560)
>     at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>     at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91) 
> StatefulInstanceInterceptor is not executed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 08:51:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 4 Jun 2009 08:51:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-721) Binds with similar
 pointcut expressions are ignored
In-Reply-To: <10693694.1239946822969.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23824140.1244119916593.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAOP-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470605#action_12470605 ] 

Carlo de Wolf commented on JBAOP-721:
-------------------------------------

Ah, I have an interceptor-ref to a non-existent interceptor.

<interceptor class="org.jboss.ejb3.test.tx.common.SynchronizationActionInterceptor" scope="PER_VM"/>

<interceptor-ref name="org.jboss.ejb3.tx.test.common.SynchronizationActionInterceptor"/>

Both the deployment of beans and the a proper error for this scenario must be fixed.

> Binds with similar pointcut expressions are ignored
> ---------------------------------------------------
>
>                 Key: JBAOP-721
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-721
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.0.GA
>         Environment: Branch_5_x @ 87425
>            Reporter: Carlo de Wolf
>            Assignee: Flavia Rainone
>            Priority: Critical
>             Fix For: 2.1.2.GA, 2.2.0.GA
>
>
> Given the following descriptor:
> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/trunk/core/src/main/resources/ejb3-interceptors-aop.xml?revision=87350&view=markup
> 04-16-2009 09:47:58:  ERROR: java.lang.NullPointerException
>     at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
>     at org.jboss.ejb3.tx.TxInterceptor$Never.invoke(TxInterceptor.java:63)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>     at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:560)
>     at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>     at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91) 
> StatefulInstanceInterceptor is not executed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 09:48:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Thu, 4 Jun 2009 09:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2108) A rule does not
 fire for all objects satisfying the rule code.
Message-ID: <23289330.1244123336579.JavaMail.jira@cloud.prod.atl2.jboss.com>

A rule does not fire for all objects satisfying the rule code.
--------------------------------------------------------------

                 Key: JBRULES-2108
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2108
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 4.0.7
            Reporter: Andrey Nechaev
            Assignee: Mark Proctor


The following code shows the problem:
public class DroolsTest {
	private final static int NUM_FACTS = 20;
	private final static String rule = "" + 
		"package test\n" + 
		"import com.test.DroolsTest;\n" + 
		"import com.test.DroolsTest.Foo;\n" +
		"import com.test.DroolsTest.Bar;\n" +
		"rule test\n" + 
			"\twhen\n" + 
				"\t\tFoo($p : id < " + Integer.toString(NUM_FACTS) + ") && Bar(id == $p)\n" +
			"\tthen\n" +
				"\t\tDroolsTest.incCounter();\n" +
		"end";
	
	private static int counter;
	
	public static class Foo {
		private final int id;
		
		Foo(int id) {
			this.id = id;
		}
		
		public int getId() {
			return id;
		}
	}
	
	public static class Bar {
		private final int id;
		
		Bar(int id) {
			this.id = id;
		}
		
		public int getId() {
			return id;
		}
	}
	
	public static void main(String[] args) throws Exception {
		RuleBase rb;
		WorkingMemory wm;
		counter = 0;
		
		rb = RuleBaseFactory.newRuleBase();
		wm = rb.newStatefulSession();
				
		for(int i = 0; i < NUM_FACTS; i++) {
			wm.insert(new Foo(i));
			wm.insert(new Bar(i));
		}
		PackageBuilder bld = new PackageBuilder();
		bld.addPackageFromDrl(new StringReader(rule));
		
		rb.addPackage(bld.getPackage());
		System.out.println(counter == NUM_FACTS ? "passed" : "failed");
	}
	
	public static void incCounter() {
		++counter;
	}
}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 09:52:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Thu, 4 Jun 2009 09:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2108) A rule does not
 fire for all objects satisfying the rule code.
In-Reply-To: <23289330.1244123336579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32419810.1244123576472.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470618#action_12470618 ] 

Andrey Nechaev commented on JBRULES-2108:
-----------------------------------------

It seems there is a bug in the FieldIndexHashTableFullIterator iterator's next() method. When a table's item contains more than one element, all the elements except the first one are skipped. Attachement is the patch resolving the issue, and it works in our environment.

> A rule does not fire for all objects satisfying the rule code.
> --------------------------------------------------------------
>
>                 Key: JBRULES-2108
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2108
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 4.0.7
>            Reporter: Andrey Nechaev
>            Assignee: Mark Proctor
>
> The following code shows the problem:
> public class DroolsTest {
> 	private final static int NUM_FACTS = 20;
> 	private final static String rule = "" + 
> 		"package test\n" + 
> 		"import com.test.DroolsTest;\n" + 
> 		"import com.test.DroolsTest.Foo;\n" +
> 		"import com.test.DroolsTest.Bar;\n" +
> 		"rule test\n" + 
> 			"\twhen\n" + 
> 				"\t\tFoo($p : id < " + Integer.toString(NUM_FACTS) + ") && Bar(id == $p)\n" +
> 			"\tthen\n" +
> 				"\t\tDroolsTest.incCounter();\n" +
> 		"end";
> 	
> 	private static int counter;
> 	
> 	public static class Foo {
> 		private final int id;
> 		
> 		Foo(int id) {
> 			this.id = id;
> 		}
> 		
> 		public int getId() {
> 			return id;
> 		}
> 	}
> 	
> 	public static class Bar {
> 		private final int id;
> 		
> 		Bar(int id) {
> 			this.id = id;
> 		}
> 		
> 		public int getId() {
> 			return id;
> 		}
> 	}
> 	
> 	public static void main(String[] args) throws Exception {
> 		RuleBase rb;
> 		WorkingMemory wm;
> 		counter = 0;
> 		
> 		rb = RuleBaseFactory.newRuleBase();
> 		wm = rb.newStatefulSession();
> 				
> 		for(int i = 0; i < NUM_FACTS; i++) {
> 			wm.insert(new Foo(i));
> 			wm.insert(new Bar(i));
> 		}
> 		PackageBuilder bld = new PackageBuilder();
> 		bld.addPackageFromDrl(new StringReader(rule));
> 		
> 		rb.addPackage(bld.getPackage());
> 		System.out.println(counter == NUM_FACTS ? "passed" : "failed");
> 	}
> 	
> 	public static void incCounter() {
> 		++counter;
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 09:54:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Thu, 4 Jun 2009 09:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2108) A rule does not
 fire for all objects satisfying the rule code.
In-Reply-To: <23289330.1244123336579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23826105.1244123696504.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrey Nechaev updated JBRULES-2108:
------------------------------------

    Attachment: patch


> A rule does not fire for all objects satisfying the rule code.
> --------------------------------------------------------------
>
>                 Key: JBRULES-2108
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2108
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 4.0.7
>            Reporter: Andrey Nechaev
>            Assignee: Mark Proctor
>         Attachments: patch
>
>
> The following code shows the problem:
> public class DroolsTest {
> 	private final static int NUM_FACTS = 20;
> 	private final static String rule = "" + 
> 		"package test\n" + 
> 		"import com.test.DroolsTest;\n" + 
> 		"import com.test.DroolsTest.Foo;\n" +
> 		"import com.test.DroolsTest.Bar;\n" +
> 		"rule test\n" + 
> 			"\twhen\n" + 
> 				"\t\tFoo($p : id < " + Integer.toString(NUM_FACTS) + ") && Bar(id == $p)\n" +
> 			"\tthen\n" +
> 				"\t\tDroolsTest.incCounter();\n" +
> 		"end";
> 	
> 	private static int counter;
> 	
> 	public static class Foo {
> 		private final int id;
> 		
> 		Foo(int id) {
> 			this.id = id;
> 		}
> 		
> 		public int getId() {
> 			return id;
> 		}
> 	}
> 	
> 	public static class Bar {
> 		private final int id;
> 		
> 		Bar(int id) {
> 			this.id = id;
> 		}
> 		
> 		public int getId() {
> 			return id;
> 		}
> 	}
> 	
> 	public static void main(String[] args) throws Exception {
> 		RuleBase rb;
> 		WorkingMemory wm;
> 		counter = 0;
> 		
> 		rb = RuleBaseFactory.newRuleBase();
> 		wm = rb.newStatefulSession();
> 				
> 		for(int i = 0; i < NUM_FACTS; i++) {
> 			wm.insert(new Foo(i));
> 			wm.insert(new Bar(i));
> 		}
> 		PackageBuilder bld = new PackageBuilder();
> 		bld.addPackageFromDrl(new StringReader(rule));
> 		
> 		rb.addPackage(bld.getPackage());
> 		System.out.println(counter == NUM_FACTS ? "passed" : "failed");
> 	}
> 	
> 	public static void incCounter() {
> 		++counter;
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:08:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Thu, 4 Jun 2009 10:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2392) Selenium tests
	for XSS
In-Reply-To: <23069268.1242226847011.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8499719.1244124536796.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470622#action_12470622 ] 

Viliam Rockai commented on JBPORTAL-2392:
-----------------------------------------

Qestions:

Identity admin: It is needed to add XSS testing to search input in identity admin? no error message is popped up and the user (xss string) is not found of course
WSRP: producer configuration - typing a string into Registration policy class name gives me an error, but typiing it into Registration property validator class name does not. everything seems to work but the error message is missing. is it ok?



> Selenium tests for XSS
> ----------------------
>
>                 Key: JBPORTAL-2392
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2392
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal QA
>            Reporter: Viliam Rockai
>            Assignee: Viliam Rockai
>
> Testing XSS on inputs in portal GUI had to be implemented.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:14:57 2009
From: jira-events at lists.jboss.org (Graham Gear (JIRA))
Date: Thu, 4 Jun 2009 10:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2109) Upload of
 Resource to Guvnor
 with multiple "." in file name causes resource type identification issues
Message-ID: <20350008.1244124897030.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upload of Resource to Guvnor with multiple "." in file name causes resource type identification issues
------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2109
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2109
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-guvnor
    Affects Versions: 5.0.1.FINAL
            Reporter: Graham Gear
            Assignee: Mark Proctor
            Priority: Minor


It seems the resource type identification is based on the file suffix of the resource being uploaded but matches against the first, not last "." in the filename to determine the suffix. This causes issue if the resource includes multiple "." which is valid under most file systems. It is also common for model JARs to include a version number with an extra ".", eg:

application-model-1.0.0.jar

The issue can be reproduced by uploading a model, DRL, RF etc to the Guvnor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:18:56 2009
From: jira-events at lists.jboss.org (Graham Gear (JIRA))
Date: Thu, 4 Jun 2009 10:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2109) Upload of
 Resource to Guvnor
 with multiple "." in file name causes resource type identification issues
In-Reply-To: <20350008.1244124897030.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26376719.1244125136574.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Graham Gear updated JBRULES-2109:
---------------------------------


Note that this is also evident from the WebDAV interfaces (JBoss Dev Studio / Cadaver etc)

> Upload of Resource to Guvnor with multiple "." in file name causes resource type identification issues
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2109
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2109
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Graham Gear
>            Assignee: Mark Proctor
>            Priority: Minor
>
> It seems the resource type identification is based on the file suffix of the resource being uploaded but matches against the first, not last "." in the filename to determine the suffix. This causes issue if the resource includes multiple "." which is valid under most file systems. It is also common for model JARs to include a version number with an extra ".", eg:
> application-model-1.0.0.jar
> The issue can be reproduced by uploading a model, DRL, RF etc to the Guvnor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:23:57 2009
From: jira-events at lists.jboss.org (Graham Gear (JIRA))
Date: Thu, 4 Jun 2009 10:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2110) Upload of
 RuleFlow with ".rf"
 suffix to Guvnor through WebDAV does not get correctly identified as a
 RuleFlow
Message-ID: <21846412.1244125437026.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow
-------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2110
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2110
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.1.FINAL
            Reporter: Graham Gear
            Assignee: Mark Proctor


Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow.

To reproduce, add a *.rf resource through JBoss Dev Studio or WebDAV client (eg cadaver) and see the resource get itemised incorrectly as a *.drl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:23:57 2009
From: jira-events at lists.jboss.org (Graham Gear (JIRA))
Date: Thu, 4 Jun 2009 10:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2110) Upload of
 RuleFlow with ".rf"
 suffix to Guvnor through WebDAV does not get correctly identified as a
 RuleFlow
In-Reply-To: <21846412.1244125437026.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32023092.1244125437215.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Graham Gear updated JBRULES-2110:
---------------------------------

    Component/s: drools-guvnor


> Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2110
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2110
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Graham Gear
>            Assignee: Mark Proctor
>
> Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow.
> To reproduce, add a *.rf resource through JBoss Dev Studio or WebDAV client (eg cadaver) and see the resource get itemised incorrectly as a *.drl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:27:57 2009
From: jira-events at lists.jboss.org (Martin Vecera (JIRA))
Date: Thu, 4 Jun 2009 10:27:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4211) Detecting
 OutOfMemoryErrors in Servers in the Test Suite
In-Reply-To: <28142178.1174172252579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29836505.1244125677795.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Vecera reassigned JBAS-4211:
-----------------------------------

    Assignee: Shelly McGowan  (was: Martin Vecera)


Hello Shelly, I'm no longer working on this issue, and I don't think it's going to be finished ever.

> Detecting OutOfMemoryErrors in Servers in the Test Suite
> --------------------------------------------------------
>
>                 Key: JBAS-4211
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4211
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Ryan Campbell
>            Assignee: Shelly McGowan
>         Attachments: dist.tar.bz2
>
>   Original Estimate: 3 days
>          Time Spent: 2 days, 2 hours
>  Remaining Estimate: 6 hours
>
> We need a custom test runner which checks for OOME's in any running servers between each test.  Optionally, only check for this after a failed test.
> See the discussion for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:27:57 2009
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Thu, 4 Jun 2009 10:27:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2392) Selenium tests
	for XSS
In-Reply-To: <23069268.1242226847011.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20201470.1244125677388.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470628#action_12470628 ] 

Prabhat Jha commented on JBPORTAL-2392:
---------------------------------------

Yes, we need to add XSS tests for Identity admin as well.
For WSRP, it should add error in both places. But as long as it's not letting bad strings to go, it's okay.

> Selenium tests for XSS
> ----------------------
>
>                 Key: JBPORTAL-2392
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2392
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal QA
>            Reporter: Viliam Rockai
>            Assignee: Viliam Rockai
>
> Testing XSS on inputs in portal GUI had to be implemented.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:35:58 2009
From: jira-events at lists.jboss.org (Chris Kulinski (JIRA))
Date: Thu, 4 Jun 2009 10:35:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4012) ClassLoaderUtils
 recurses into .war directories
In-Reply-To: <28298238.1169670354541.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19246669.1244126158569.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470632#action_12470632 ] 

Chris Kulinski commented on JBAS-4012:
--------------------------------------

David's fix works well for us.  For one application of ours, we've improved our JBoss startup time from 1 minute 30 seconds to 19 seconds using this fix.  That's amazing!

The only issue we encountered is that the patch that David submitted is actually backwards.  Below is the patch to ClassLoaderUtils.java that we're using.  The first 2 sections of diff are to add better trace logging.  You really only need the last section of diff for the actual fix.  This diff is from the JBoss 4.2.2.GA source.

Patch the source, compile the class and then update jboss-jmx.jar with the new ClassLoaderUtils$FileIterator.class.

--- ./jmx/src/main/org/jboss/mx/loading/ClassLoaderUtils.java   Wed Jun  3 15:00:46 2009
+++ ../jboss-jmx.jar/org/jboss/mx/loading/ClassLoaderUtils.java Tue Jun  2 16:54:34 2009
@@ -472,9 +472,10 @@
          String name = start.getName();
          // Don't recurse into wars
          boolean isWar = name.endsWith(".war");
-         if( isWar )
-            currentListing = new File[0];
-         else
+         if( isWar ) {
+         log.trace("war, not recursing");
+             currentListing = new File[0];
+         } else
             currentListing = start.listFiles();
       }
       FileIterator(File start, FileFilter filter)
@@ -482,9 +483,10 @@
          String name = start.getName();
          // Don't recurse into wars
          boolean isWar = name.endsWith(".war");
-         if( isWar )
-            currentListing = new File[0];
-         else
+         if( isWar ) {
+             log.trace("war, not recursing");
+             currentListing = new File[0];
+         } else
             currentListing = start.listFiles(filter);
          this.filter = filter;
       }
@@ -497,7 +499,11 @@
             do
             {
                File nextDir = (File) subDirectories.removeFirst();
-               currentListing = nextDir.listFiles(filter);
+               if(nextDir.getName().endsWith(".war")){
+                    currentListing = new File[0];
+               } else {
+                    currentListing = nextDir.listFiles(filter);
+               }
             } while( currentListing.length == 0 && subDirectories.size() > 0 );
             index = 0;
          }


> ClassLoaderUtils recurses into .war directories
> -----------------------------------------------
>
>                 Key: JBAS-4012
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4012
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: windows xp, java 1.5.0_09
>            Reporter: David
>            Assignee: Scott M Stark
>            Priority: Minor
>
> ClassLoaderUtils has logic that is supposed to prevent indexing/scanning of .war directories.  This was an issue fixed earlier in 3.2.6, reported in a support case: 00002351
> The following patch is also needed in order to fully prevent indexing in .war directories:
> $ diff -u src/org/jboss/mx/loading/ClassLoaderUtils.java /khub/opensource/jboss-4.0.5.GA-src/jmx/src/main/org/jboss/mx/loading/ClassLoaderUtils.java
> --- src/org/jboss/mx/loading/ClassLoaderUtils.java      2007-01-24 14:27:27.607071000 -0500
> +++ /khub/opensource/jboss-4.0.5.GA-src/jmx/src/main/org/jboss/mx/loading/ClassLoaderUtils.java 2006-10-16 23:37:24.000000000 -0400
> @@ -472,27 +472,21 @@
>           String name = start.getName();
>           // Don't recurse into wars
>           boolean isWar = name.endsWith(".war");
> -         if( isWar ) {
> -            log.trace("war, not recursing");
> +         if( isWar )
>              currentListing = new File[0];
> -         }
> -         else {
> +         else
>              currentListing = start.listFiles();
> -         }
>        }
>        FileIterator(File start, FileFilter filter)
>        {
>           String name = start.getName();
>           // Don't recurse into wars
>           boolean isWar = name.endsWith(".war");
> -         if( isWar ) {
> -            log.trace("war, not recursing");
> +         if( isWar )
>              currentListing = new File[0];
> -         }
> -         else {
> +         else
>              currentListing = start.listFiles(filter);
> -            this.filter = filter;
> -         }
> +         this.filter = filter;
>        }
>        File getNextEntry()
> @@ -503,13 +497,7 @@
>              do
>              {
>                 File nextDir = (File) subDirectories.removeFirst();
> -               if (nextDir.getName().endsWith(".war")) {
> -                  log.trace("war, not recursing");
> -                  currentListing = new File[0];
> -               }
> -               else {
> -                  currentListing = nextDir.listFiles(filter);
> -               }
> +               currentListing = nextDir.listFiles(filter);
>              } while( currentListing.length == 0 && subDirectories.size() > 0 );
>              index = 0;
>           }
> The stack trace during startup is here:
> "main" prio=6 tid=0x1bcadc70 nid=0xec4 runnable [0x1c02e000..0x1c02fb18]
> 	at java.io.WinNTFileSystem.list(Native Method)
> 	at java.io.File.list(File.java:937)
> 	at java.io.File.listFiles(File.java:1093)
> 	at org.jboss.mx.loading.ClassLoaderUtils$FileIterator.getNextEntry(ClassLoaderUtils.java:500)
> 	at org.jboss.mx.loading.ClassLoaderUtils$ClassPathIterator.getNextEntry(ClassLoaderUtils.java:617)
> 	at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap(ClassLoaderUtils.java:319)
> 	at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap(ClassLoaderUtils.java:253)
> 	at org.jboss.mx.loading.UnifiedLoaderRepository3.updatePackageMap(UnifiedLoaderRepository3.java:783)
> 	at org.jboss.mx.loading.UnifiedLoaderRepository3.addRepositoryClassLoader(UnifiedLoaderRepository3.java:740)
> 	- locked <0x07aafcf0> (a EDU.oswego.cs.dl.util.concurrent.CopyOnWriteArraySet)
> 	at org.jboss.mx.loading.UnifiedLoaderRepository3.addClassLoader(UnifiedLoaderRepository3.java:662)
> 	at org.jboss.mx.loading.UnifiedLoaderRepository3.registerClassLoader(UnifiedLoaderRepository3.java:946)
> 	at org.jboss.mx.loading.UnifiedLoaderRepository3.newClassLoader(UnifiedLoaderRepository3.java:168)
> 	at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.deployment.DeploymentInfo.createClassLoaders(DeploymentInfo.java:280)
> 	at org.jboss.deployment.MainDeployer.init(MainDeployer.java:874)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:809)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> 	at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	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:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy9.deploy(Unknown Source)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
> 	- locked <0x07e0e0d8> (a org.jboss.deployment.scanner.URLDeploymentScanner)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
> 	- locked <0x07ec9400> (a org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> 	at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> 	at $Proxy0.start(Unknown Source)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
> 	- locked <0x07af6660> (a org.jboss.system.ServiceController)
> 	at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy4.start(Unknown Source)
> 	at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	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:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy5.deploy(Unknown Source)
> 	at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
> 	at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
> 	at org.jboss.Main.boot(Main.java:200)
> 	at org.jboss.Main$1.run(Main.java:490)
> 	at java.lang.Thread.run(Thread.java:595)
> with trace logging on you see:

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:39:56 2009
From: jira-events at lists.jboss.org (Graham Gear (JIRA))
Date: Thu, 4 Jun 2009 10:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2110) Upload of
 RuleFlow with ".rf"
 suffix to Guvnor through WebDAV does not get correctly identified as a
 RuleFlow
In-Reply-To: <21846412.1244125437026.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16697068.1244126396725.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Graham Gear updated JBRULES-2110:
---------------------------------


Actually, this is not related to the resource type (*.rf) but the format of the file name being uploaded as per the examples below:

Local file name  -> Guvnor import via Dev Studio / Cadaver -> Guvnor Resource Name

SubmitApplication.rf   ->   ->  SubmitApplication.drl
Submit.rf   ->   ->  Submit.rf

This could be a category of greater issue within the resource identification code of the Guvnor.



> Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2110
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2110
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Graham Gear
>            Assignee: Mark Proctor
>
> Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow.
> To reproduce, add a *.rf resource through JBoss Dev Studio or WebDAV client (eg cadaver) and see the resource get itemised incorrectly as a *.drl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:46:56 2009
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 4 Jun 2009 10:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-6328) jmx-console: Back to
 MBean button causes error
In-Reply-To: <29723732.1229531464862.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <723396.1244126816789.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dimitris Andreadis closed JBAS-6328.
------------------------------------



> jmx-console: Back to MBean button causes error
> ----------------------------------------------
>
>                 Key: JBAS-6328
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6328
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX/Web Console
>    Affects Versions: JBossAS-5.0.0.GA
>            Reporter: Martin Vecera
>            Assignee: Dimitris Andreadis
>            Priority: Critical
>             Fix For: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: ApplyChangesButton.patch, JBAS-6328.patch
>
>
> After invoking an operation in JMX Console (e.g. startDatabaseManager under http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB), the button "Back to MBean" on result page causes Error 500.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:49:56 2009
From: jira-events at lists.jboss.org (Guillaume Jeudy (JIRA))
Date: Thu, 4 Jun 2009 10:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-523) Implement
 topic hierarchies
In-Reply-To: <16561250.1155738026493.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28470976.1244126996891.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470635#action_12470635 ] 

Guillaume Jeudy commented on JBMESSAGING-523:
---------------------------------------------

is there any documentation on how to use this feature in JBM 2.0 ?  I couldnt find any. Besides I only see a 2.0 alpha release but this JIRA states it was implemented in 2.0 beta...

> Implement topic hierarchies
> ---------------------------
>
>                 Key: JBMESSAGING-523
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-523
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Andy Taylor
>            Priority: Critical
>             Fix For: 2.0.0 Beta
>
>
> Implement topic hierarchies so a subscription can subscribe to a wildcard, e.g. news.* and will receive all messages sent to topics news.uk, news.usa, news.usa.local etc etc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:49:57 2009
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 4 Jun 2009 10:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2111) In-Pattern
 RestrictionConnectiveDescrs (&& and ||) do not support bindings and
 restrictions at the same time
Message-ID: <27444468.1244126997455.JavaMail.jira@cloud.prod.atl2.jboss.com>

In-Pattern RestrictionConnectiveDescrs (&& and ||) do not support bindings and restrictions at the same time
------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2111
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2111
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.1.FINAL, 5.0.0.FINAL, 5.0.0.CR1, 5.0.0.M5,  5.0.0.M4, 5.0.0.M3,  5.0.0.M2, 5.0.0.M1
         Environment: any
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Critical
             Fix For: FUTURE


when trying to use connectives with restrictions and bindings, as in :
       Type( $f1: field1 op1 expr1 && $f2 : field2 op2 expr2)
the fieldRestrictions are ignored by the parser and only the bindings are retained.
Thus, reading the values of $f1 or $f2 returns the right value, but the restrictions
(field op expr) are not generated

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:52:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 4 Jun 2009 10:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2111) In-Pattern
 RestrictionConnectiveDescrs (&& and ||) do not support bindings and
 restrictions at the same time
In-Reply-To: <27444468.1244126997455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16584045.1244127176548.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned JBRULES-2111:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> In-Pattern RestrictionConnectiveDescrs (&& and ||) do not support bindings and restrictions at the same time
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2111
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2111
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.0.0.M1,  5.0.0.M2, 5.0.0.M3,  5.0.0.M4, 5.0.0.M5, 5.0.0.CR1, 5.0.0.FINAL, 5.0.1.FINAL
>         Environment: any
>            Reporter: Davide Sottara
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: FUTURE
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> when trying to use connectives with restrictions and bindings, as in :
>        Type( $f1: field1 op1 expr1 && $f2 : field2 op2 expr2)
> the fieldRestrictions are ignored by the parser and only the bindings are retained.
> Thus, reading the values of $f1 or $f2 returns the right value, but the restrictions
> (field op expr) are not generated

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:54:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 4 Jun 2009 10:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2111) In-Pattern
 RestrictionConnectiveDescrs (&& and ||) do not support bindings and
 restrictions at the same time
In-Reply-To: <27444468.1244126997455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18473120.1244127296522.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli updated JBRULES-2111:
-----------------------------------

        Fix Version/s: 5.1.0.M1
                           (was: FUTURE)
    Affects Version/s:     (was: 5.0.0.M1)
                           (was:  5.0.0.M2)


> In-Pattern RestrictionConnectiveDescrs (&& and ||) do not support bindings and restrictions at the same time
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2111
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2111
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.0.0.M3,  5.0.0.M4, 5.0.0.M5, 5.0.0.CR1, 5.0.0.FINAL, 5.0.1.FINAL
>         Environment: any
>            Reporter: Davide Sottara
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.1.0.M1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> when trying to use connectives with restrictions and bindings, as in :
>        Type( $f1: field1 op1 expr1 && $f2 : field2 op2 expr2)
> the fieldRestrictions are ignored by the parser and only the bindings are retained.
> Thus, reading the values of $f1 or $f2 returns the right value, but the restrictions
> (field op expr) are not generated

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 10:56:56 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Thu, 4 Jun 2009 10:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-523) Implement
 topic hierarchies
In-Reply-To: <16561250.1155738026493.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11183527.1244127416609.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470636#action_12470636 ] 

Andy Taylor commented on JBMESSAGING-523:
-----------------------------------------

jbm 2 beta has not been released yet altho its imminent. This will contain documentation on how to use it.

> Implement topic hierarchies
> ---------------------------
>
>                 Key: JBMESSAGING-523
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-523
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Andy Taylor
>            Priority: Critical
>             Fix For: 2.0.0 Beta
>
>
> Implement topic hierarchies so a subscription can subscribe to a wildcard, e.g. news.* and will receive all messages sent to topics news.uk, news.usa, news.usa.local etc etc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 11:01:01 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 4 Jun 2009 11:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-523) Implement
 topic hierarchies
In-Reply-To: <16561250.1155738026493.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31408497.1244127661247.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470639#action_12470639 ] 

Tim Fox commented on JBMESSAGING-523:
-------------------------------------

If you can't wait, then this is in SVN TRUNK

> Implement topic hierarchies
> ---------------------------
>
>                 Key: JBMESSAGING-523
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-523
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Andy Taylor
>            Priority: Critical
>             Fix For: 2.0.0 Beta
>
>
> Implement topic hierarchies so a subscription can subscribe to a wildcard, e.g. news.* and will receive all messages sent to topics news.uk, news.usa, news.usa.local etc etc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 11:07:09 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 4 Jun 2009 11:07:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1844) Retry operations
 after an EJBTransactionRolledbackException
Message-ID: <16255062.1244128029237.JavaMail.jira@cloud.prod.atl2.jboss.com>

Retry operations after an EJBTransactionRolledbackException
-----------------------------------------------------------

                 Key: EJBTHREE-1844
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1844
             Project: EJB 3.0
          Issue Type: Feature Request
          Components: transactions
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf


By either annotating a bean or its methods, the applicable methods will retry the operation if an EJBTransactionRolledbackException occurs.
@TransactionRetry(numRetries=4, waitTime=1, waitTimeUnit=TimeUnit.SECONDS)

numRetries specifies how many times an operation will be tried.
waitTime specified the amount of time to wait before retrying with the unit of time specified in waitTimeUnit.

Default is 3 retries and 1000 milliseconds wait time after an EJBTransactionRolledbackException.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 11:12:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 4 Jun 2009 11:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1484) Rename base
	package name
In-Reply-To: <17920878.1231877584176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21876548.1244128376651.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1484:
---------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0 Beta)


> Rename base package name
> ------------------------
>
>                 Key: JBMESSAGING-1484
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1484
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.CR1
>
>
> Rename org.jboss.messaging to something else.
> Suggestions are:
> org.jboss.jbm
> ....

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 11:43:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 4 Jun 2009 11:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1638) Ordering
 Group messages delivery is not correctly handled after XA prepare()
Message-ID: <19894567.1244130236527.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ordering Group messages delivery is not correctly handled after XA prepare() 
-----------------------------------------------------------------------------

                 Key: JBMESSAGING-1638
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1638
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.4.GA, 1.4.0.SP3.CP08
            Reporter: Howard Gao
            Assignee: Howard Gao
             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA



In XA environment, if one ordering group message is received within a transaction but not committed, the next message can't be received. The problem is that after the transaction is prepared, the next message is delivered, thus broken the ordering.





-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 11:45:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 4 Jun 2009 11:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1638) Ordering
 Group messages delivery is not correctly handled after XA prepare()
In-Reply-To: <19894567.1244130236527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5289374.1244130356634.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1638:
------------------------------------

    Description: 

In XA environment, if one ordering group message is received within a transaction but not committed, the next message can't be received. The problem is that after the transaction is prepared, the next message is delivered, thus breaking the ordering.





  was:

In XA environment, if one ordering group message is received within a transaction but not committed, the next message can't be received. The problem is that after the transaction is prepared, the next message is delivered, thus broken the ordering.







> Ordering Group messages delivery is not correctly handled after XA prepare() 
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1638
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1638
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In XA environment, if one ordering group message is received within a transaction but not committed, the next message can't be received. The problem is that after the transaction is prepared, the next message is delivered, thus breaking the ordering.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 12:18:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 4 Jun 2009 12:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-140) Define javac target
 for build consistency
In-Reply-To: <3295821.1244048854856.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9761296.1244132336891.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-140:
-------------------------------

    Fix Version/s: JBossWeb-2.0.0.GA_CP11


> Define javac target for build consistency
> -----------------------------------------
>
>                 Key: JBWEB-140
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-140
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Mike Millson
>             Fix For: JBossWeb-2.0.0.GA_CP11
>
>         Attachments: build.xml.patch
>
>
> Currently the build will target the JVM version being used to run the ant build task. Add the ability to build with JDK 1.6 by specifying the javac target to 1.5.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 12:22:56 2009
From: jira-events at lists.jboss.org (Nick Boldt (JIRA))
Date: Thu, 4 Jun 2009 12:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2112) Cannot build
 Drools IDE w/ OpenJDK 6 (vm crashes)
Message-ID: <4361993.1244132576401.JavaMail.jira@cloud.prod.atl2.jboss.com>

Cannot build Drools IDE w/ OpenJDK 6 (vm crashes)
-------------------------------------------------

                 Key: JBRULES-2112
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2112
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Nick Boldt
            Assignee: Mark Proctor


Drools 5.0.x can compile with OpenJDK6; Drools 5.1 cannot. See attached logs. 

This prevents the JBoss Tools build from being able to run locally on Fedora w/ the out-of-box JVM (Open JDK 6).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 12:24:56 2009
From: jira-events at lists.jboss.org (Nick Boldt (JIRA))
Date: Thu, 4 Jun 2009 12:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2112) Cannot build
 Drools IDE w/ OpenJDK 6 (vm crashes)
In-Reply-To: <4361993.1244132576401.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24714234.1244132696587.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nick Boldt updated JBRULES-2112:
--------------------------------

    Attachment: hs_err_pid29622.log
                build.log.20090604-0200.txt


Attached are the build log (see line 425) and the referenced hs_err_pid*.log file.

> Cannot build Drools IDE w/ OpenJDK 6 (vm crashes)
> -------------------------------------------------
>
>                 Key: JBRULES-2112
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2112
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Nick Boldt
>            Assignee: Mark Proctor
>         Attachments: build.log.20090604-0200.txt, hs_err_pid29622.log
>
>
> Drools 5.0.x can compile with OpenJDK6; Drools 5.1 cannot. See attached logs. 
> This prevents the JBoss Tools build from being able to run locally on Fedora w/ the out-of-box JVM (Open JDK 6).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 12:24:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 4 Jun 2009 12:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBWEB-140) Define javac target
 for build consistency
In-Reply-To: <3295821.1244048854856.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8814232.1244132696463.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson resolved JBWEB-140.
--------------------------------

    Resolution: Done


> Define javac target for build consistency
> -----------------------------------------
>
>                 Key: JBWEB-140
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-140
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Mike Millson
>             Fix For: JBossWeb-2.0.0.GA_CP11
>
>         Attachments: build.xml.patch
>
>
> Currently the build will target the JVM version being used to run the ant build task. Add the ability to build with JDK 1.6 by specifying the javac target to 1.5.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 12:31:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 4 Jun 2009 12:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1639) Validate
 configuration values programmatically
Message-ID: <9257056.1244133116418.JavaMail.jira@cloud.prod.atl2.jboss.com>

Validate configuration values programmatically
----------------------------------------------

                 Key: JBMESSAGING-1639
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1639
             Project: JBoss Messaging
          Issue Type: Feature Request
          Components: Configuration and Management
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 2.0.0.CR1


using XSD to validate configuration values make the schema more complex and error-prone (the error messages are hard to understand too).

We should move to programmatic validation. E.g. in FileConfiguration, when we read the values from the configuration, we could add a validation step to check values (e.g. must be -1 or > 0 which is impossible to express in a XML Schema)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 12:43:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 4 Jun 2009 12:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-89) Make the Server
 start message look more like the legacy
Message-ID: <26051330.1244133836509.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make the Server start message look more like the legacy
-------------------------------------------------------

                 Key: JBBOOT-89
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-89
             Project: JBoss Bootstrap
          Issue Type: Feature Request
          Components: impl-base
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger


(12:17:53 PM) bstansberry: ALR: request you make "Started: org.jboss.bootstrap.impl.as.server.JBossASServerImpl at bc92535 in 1m:3s:597ms" read more like the old msg. Something easy to search for in server.log
(12:18:28 PM) bstansberry: I used to search for "Started in"; in AS 4 for "MicroKernel"
(12:18:31 PM) ALR: bstansberry: k.  https://jira.jboss.org/jira/browse/JBBOOT-83

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 12:55:57 2009
From: jira-events at lists.jboss.org (Mike Lewis (JIRA))
Date: Thu, 4 Jun 2009 12:55:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-733) runtime
 instrumentation classloading can't find class for array of bytes [B
Message-ID: <6914195.1244134557165.JavaMail.jira@cloud.prod.atl2.jboss.com>

runtime instrumentation classloading can't find class for array of bytes [B
---------------------------------------------------------------------------

                 Key: JBAOP-733
                 URL: https://jira.jboss.org/jira/browse/JBAOP-733
             Project: JBoss AOP
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.1.GA
         Environment: OS: 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux
Java: Java(TM) SE Runtime Environment (build 1.6.0_10-b33) 
JBoss AS: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221053)
            Reporter: Mike Lewis


Our app has conf/bootstrap/aop.xml configured with:
 
enableLoadTimeWeaving = true
optimized = false
instrumentor = org.jboss.aop.instrument.ClassicInstrumentor

Our class TLSByteArrayOutputStream has a field tagged for the ThreadBased aspect:

@Threadbased protected byte[] buffer;

Our .aop archive has META-INF/jboss-aop.xml with:









-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 13:19:08 2009
From: jira-events at lists.jboss.org (Mike Lewis (JIRA))
Date: Thu, 4 Jun 2009 13:19:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-733) runtime
 instrumentation classloading can't find class for array of bytes [B
In-Reply-To: <6914195.1244134557165.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31163484.1244135948659.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAOP-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Lewis updated JBAOP-733:
-----------------------------

    Description: 
Our app has conf/bootstrap/aop.xml configured with:
 
enableLoadTimeWeaving = true
optimized = false
verbose = true
instrumentor = org.jboss.aop.instrument.ClassicInstrumentor

Our class TLSByteArrayOutputStream has a field tagged for the ThreadBased aspect:

@Threadbased protected byte[] buffer;

Our .aop archive has META-INF/jboss-aop.xml with:

<aspect class="org.jboss.aspects.ThreadbasedAspect" scope="PER_JOINPOINT"/>
<bind pointcut="field(* *->@org.jboss.aspects.Threadbased)">
  <advice name="access" aspect="org.jboss.aspects.ThreadbasedAspect"/>
</bind>

The error on the console during startup:

10:01:28,708 ERROR [STDERR] javassist.CannotCompileException: by javassist.bytecode.BadBytecode: cannot find [B
10:01:28,708 ERROR [STDERR] 	at javassist.CtBehavior.setBody(CtBehavior.java:370)
10:01:28,708 ERROR [STDERR] 	at javassist.CtBehavior.setBody(CtBehavior.java:334)
10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.NonOptimizedFieldAccessTransformer.buildWrappers(NonOptimizedFieldAccessTransformer.java:119)
10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.NonOptimizedFieldAccessTransformer.doBuildFieldWrappers(NonOptimizedFieldAccessTransformer.java:102)
10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.FieldAccessTransformer.buildFieldWrappers(FieldAccessTransformer.java:103)
10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:778)
10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.ClassicWeavingStrategy.translate(ClassicWeavingStrategy.java:110)
10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.AspectManager.translate(AspectManager.java:1071)
10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.AspectManager.transform(AspectManager.java:1015)
10:01:28,709 ERROR [STDERR] 	at org.jboss.aop.standalone.AOPTransformer.aspectTransform(AOPTransformer.java:87)
10:01:28,709 ERROR [STDERR] 	at org.jboss.aop.standalone.AOPTransformer.transform(AOPTransformer.java:75)
10:01:28,709 ERROR [STDERR] 	at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
10:01:28,709 ERROR [STDERR] 	at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.defineClass1(Native Method)
10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
10:01:28,709 ERROR [STDERR] 	at java.security.AccessController.doPrivileged(Native Method)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
10:01:28,709 ERROR [STDERR] 	at com.company.framework.CoreSystem.getSystemProperty(CoreSystem.java:699)
10:01:28,709 ERROR [STDERR] 	at com.company.framework.impl.CoreServlet.init(CoreServlet.java:81)
10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1048)
10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:950)
10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4122)
10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4421)
10:01:28,709 ERROR [STDERR] 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
10:01:28,709 ERROR [STDERR] 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
10:01:28,709 ERROR [STDERR] 	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
10:01:28,710 ERROR [STDERR] 	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
10:01:28,710 ERROR [STDERR] 	at org.jboss.web.deployers.WebModule.start(WebModule.java:97)
10:01:28,710 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10:01:28,710 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
10:01:28,710 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
10:01:28,710 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
10:01:28,710 ERROR [STDERR] 	at $Proxy38.start(Unknown Source)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.ServiceController.start(ServiceController.java:460)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
10:01:28,710 ERROR [STDERR] 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
10:01:28,710 ERROR [STDERR] 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
10:01:28,710 ERROR [STDERR] 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
10:01:28,711 ERROR [STDERR] 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
10:01:28,711 ERROR [STDERR] 	at org.jboss.Main.boot(Main.java:221)
10:01:28,711 ERROR [STDERR] 	at org.jboss.Main$1.run(Main.java:556)
10:01:28,711 ERROR [STDERR] 	at java.lang.Thread.run(Thread.java:619)
10:01:28,712 ERROR [STDERR] Caused by: javassist.bytecode.BadBytecode: cannot find [B
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.TypeData$TypeName.update(TypeData.java:282)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.TypeData$TypeName.setType(TypeData.java:203)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.TypeData.setType(TypeData.java:46)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:908)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:898)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:898)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:813)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:615)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:101)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:161)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:171)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:120)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:96)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:404)
10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:389)
10:01:28,712 ERROR [STDERR] 	at javassist.CtBehavior.setBody(CtBehavior.java:364)
10:01:28,712 ERROR [STDERR] 	... 105 more
10:01:28,712 ERROR [ClassicWeavingStrategy] java.lang.RuntimeException: failed to transform: com.company.rtl.io.TLSByteArrayOutputStream

with org.jboss logging set to trace, the following logs are produced:

2009-06-04 09:17:50,401 DEBUG [org.jboss.aop.instrument.JoinpointSimpleClassifier] (main) com.company.rtl.io.TLSByteArrayOutputStream.buffer:[B matches pointcut: field(* *->@org.jboss.aspects.Threadbased)
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] initiating get of [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] looking for [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] looking for [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] checking parent first for [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking parent (parentFirst)
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking parent (parentFirst)
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking parent (parentFirst)
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from pool parent - no parent pool
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking cache
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at b3e6577 org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 searching just this pool for [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 checking local cache for [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at b3e6577 org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 found [B in poolnull
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - creating
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 attempting to create [B in parent pool (parentFirst)
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 created [B null
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking cache
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 1d7b51e8 org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 searching just this pool for [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 checking local cache for [B
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 1d7b51e8 org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 found [B in poolnull
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - creating
2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 attempting to create [B in parent pool (parentFirst)
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 attempting to create [B in parent pool (parentFirst)
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 created [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 created [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking cache
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 68d39f3c org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 searching just this pool for [B
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 checking local cache for [B
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 68d39f3c org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 found [B in poolnull
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - creating
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 attempting to create [B in parent pool (parentFirst)
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 attempting to create [B in parent pool (parentFirst)
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 attempting to create [B in parent pool (parentFirst)
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 created [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 created [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 created [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1526730988 [class path: BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1526730988 [class path: BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 539342413 [class path: BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 539342413 [class path: BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1931573327 [class path: BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1931573327 [class path: BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 544899859 [class path: BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml}:] - dcl:BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,853 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 544899859 [class path: BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml}:] - dcl:BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,853 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1959325602 [class path: BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/}:] - dcl:BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1959325602 [class path: BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/}:] - dcl:BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 713962167 [class path: BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/}:] - dcl:BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 713962167 [class path: BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/}:] - dcl:BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 333633399 [class path: BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/}:] - dcl:BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 333633399 [class path: BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/}:] - dcl:BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1523167932 [class path: BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/}:] - dcl:BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1523167932 [class path: BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/}:] - dcl:BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 2115856113 [class path: BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/}:] - dcl:BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 2115856113 [class path: BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/}:] - dcl:BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1129291007 [class path: BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/}:] - dcl:BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1129291007 [class path: BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/}:] - dcl:BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1614726683 [class path: BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/}:] - dcl:BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1614726683 [class path: BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/}:] - dcl:BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] found [B in null
2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] get cached or create [B from pool parent - no parent pool
2009-06-04 09:17:50,883 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
2009-06-04 09:17:50,883 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
2009-06-04 09:17:50,883 ERROR [STDERR] (main) javassist.CannotCompileException: by javassist.bytecode.BadBytecode: cannot find [B
2009-06-04 09:17:50,928 ERROR [STDERR] (main) Caused by: javassist.bytecode.BadBytecode: cannot find [B

The same app hosted by jboss-5.0.1.GA doesn't have this problem nor does compiling with AopC.


  was:
Our app has conf/bootstrap/aop.xml configured with:
 
enableLoadTimeWeaving = true
optimized = false
instrumentor = org.jboss.aop.instrument.ClassicInstrumentor

Our class TLSByteArrayOutputStream has a field tagged for the ThreadBased aspect:

@Threadbased protected byte[] buffer;

Our .aop archive has META-INF/jboss-aop.xml with:











> runtime instrumentation classloading can't find class for array of bytes [B
> ---------------------------------------------------------------------------
>
>                 Key: JBAOP-733
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-733
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>         Environment: OS: 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux
> Java: Java(TM) SE Runtime Environment (build 1.6.0_10-b33) 
> JBoss AS: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221053)
>            Reporter: Mike Lewis
>
> Our app has conf/bootstrap/aop.xml configured with:
>  
> enableLoadTimeWeaving = true
> optimized = false
> verbose = true
> instrumentor = org.jboss.aop.instrument.ClassicInstrumentor
> Our class TLSByteArrayOutputStream has a field tagged for the ThreadBased aspect:
> @Threadbased protected byte[] buffer;
> Our .aop archive has META-INF/jboss-aop.xml with:
> <aspect class="org.jboss.aspects.ThreadbasedAspect" scope="PER_JOINPOINT"/>
> <bind pointcut="field(* *->@org.jboss.aspects.Threadbased)">
>   <advice name="access" aspect="org.jboss.aspects.ThreadbasedAspect"/>
> </bind>
> The error on the console during startup:
> 10:01:28,708 ERROR [STDERR] javassist.CannotCompileException: by javassist.bytecode.BadBytecode: cannot find [B
> 10:01:28,708 ERROR [STDERR] 	at javassist.CtBehavior.setBody(CtBehavior.java:370)
> 10:01:28,708 ERROR [STDERR] 	at javassist.CtBehavior.setBody(CtBehavior.java:334)
> 10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.NonOptimizedFieldAccessTransformer.buildWrappers(NonOptimizedFieldAccessTransformer.java:119)
> 10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.NonOptimizedFieldAccessTransformer.doBuildFieldWrappers(NonOptimizedFieldAccessTransformer.java:102)
> 10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.FieldAccessTransformer.buildFieldWrappers(FieldAccessTransformer.java:103)
> 10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:778)
> 10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.ClassicWeavingStrategy.translate(ClassicWeavingStrategy.java:110)
> 10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.AspectManager.translate(AspectManager.java:1071)
> 10:01:28,708 ERROR [STDERR] 	at org.jboss.aop.AspectManager.transform(AspectManager.java:1015)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.aop.standalone.AOPTransformer.aspectTransform(AOPTransformer.java:87)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.aop.standalone.AOPTransformer.transform(AOPTransformer.java:75)
> 10:01:28,709 ERROR [STDERR] 	at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
> 10:01:28,709 ERROR [STDERR] 	at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
> 10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.defineClass1(Native Method)
> 10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
> 10:01:28,709 ERROR [STDERR] 	at java.security.AccessController.doPrivileged(Native Method)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
> 10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> 10:01:28,709 ERROR [STDERR] 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> 10:01:28,709 ERROR [STDERR] 	at com.company.framework.CoreSystem.getSystemProperty(CoreSystem.java:699)
> 10:01:28,709 ERROR [STDERR] 	at com.company.framework.impl.CoreServlet.init(CoreServlet.java:81)
> 10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1048)
> 10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:950)
> 10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4122)
> 10:01:28,709 ERROR [STDERR] 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4421)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
> 10:01:28,709 ERROR [STDERR] 	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.web.deployers.WebModule.start(WebModule.java:97)
> 10:01:28,710 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:01:28,710 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 10:01:28,710 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 10:01:28,710 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
> 10:01:28,710 ERROR [STDERR] 	at $Proxy38.start(Unknown Source)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.ServiceController.start(ServiceController.java:460)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 10:01:28,710 ERROR [STDERR] 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.Main.boot(Main.java:221)
> 10:01:28,711 ERROR [STDERR] 	at org.jboss.Main$1.run(Main.java:556)
> 10:01:28,711 ERROR [STDERR] 	at java.lang.Thread.run(Thread.java:619)
> 10:01:28,712 ERROR [STDERR] Caused by: javassist.bytecode.BadBytecode: cannot find [B
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.TypeData$TypeName.update(TypeData.java:282)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.TypeData$TypeName.setType(TypeData.java:203)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.TypeData.setType(TypeData.java:46)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:908)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:898)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:898)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:813)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:615)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:101)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:161)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:171)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:120)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:96)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:404)
> 10:01:28,712 ERROR [STDERR] 	at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:389)
> 10:01:28,712 ERROR [STDERR] 	at javassist.CtBehavior.setBody(CtBehavior.java:364)
> 10:01:28,712 ERROR [STDERR] 	... 105 more
> 10:01:28,712 ERROR [ClassicWeavingStrategy] java.lang.RuntimeException: failed to transform: com.company.rtl.io.TLSByteArrayOutputStream
> with org.jboss logging set to trace, the following logs are produced:
> 2009-06-04 09:17:50,401 DEBUG [org.jboss.aop.instrument.JoinpointSimpleClassifier] (main) com.company.rtl.io.TLSByteArrayOutputStream.buffer:[B matches pointcut: field(* *->@org.jboss.aspects.Threadbased)
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] initiating get of [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] looking for [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] looking for [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] checking parent first for [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking parent (parentFirst)
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking parent (parentFirst)
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking parent (parentFirst)
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from pool parent - no parent pool
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking cache
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at b3e6577 org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 searching just this pool for [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 checking local cache for [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at b3e6577 org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 found [B in poolnull
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - creating
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 attempting to create [B in parent pool (parentFirst)
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 created [B null
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking cache
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 1d7b51e8 org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 searching just this pool for [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 checking local cache for [B
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 1d7b51e8 org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 found [B in poolnull
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - creating
> 2009-06-04 09:17:50,851 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 attempting to create [B in parent pool (parentFirst)
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 attempting to create [B in parent pool (parentFirst)
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 created [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 created [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - checking cache
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 68d39f3c org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 searching just this pool for [B
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 checking local cache for [B
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy] (main) org.jboss.aop.classpool.AOPClassPool$SearchLocalLoaderLoaderSearchStrategy at 68d39f3c org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 found [B in poolnull
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolToClassPoolDomainAdapter] (main) ClassPoolToDomainAdapter[32355719 org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8] get cached or create [B from BaseClassPool - creating
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 attempting to create [B in parent pool (parentFirst)
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 attempting to create [B in parent pool (parentFirst)
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 attempting to create [B in parent pool (parentFirst)
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 541607330 [class path: sun.misc.Launcher$ExtClassLoader at 35a16869:] - dcl:sun.misc.Launcher$ExtClassLoader at 35a16869 created [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1156690526 [class path: sun.misc.Launcher$AppClassLoader at 5acac268:] - dcl:sun.misc.Launcher$AppClassLoader at 5acac268 created [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.NonDelegatingClassPool] (main) org.jboss.aop.classpool.NonDelegatingClassPool at 1475697838 [class path: org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8:] - dcl:org.jboss.bootstrap.NoAnnotationURLClassLoader at 2d04faf8 created [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1526730988 [class path: BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1526730988 [class path: BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 5a56182f{aop-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 539342413 [class path: BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 539342413 [class path: BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 16fa21a4{jmx-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1931573327 [class path: BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1931573327 [class path: BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader at 662ad0d{deployers-classloader:0.0.0$MODULE} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,852 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 544899859 [class path: BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml}:] - dcl:BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,853 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 544899859 [class path: BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml}:] - dcl:BaseClassLoader at 1af1bd6{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/conf/jboss-service.xml} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,853 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1959325602 [class path: BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/}:] - dcl:BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1959325602 [class path: BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/}:] - dcl:BaseClassLoader at 4038202{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jboss-aop-jboss5.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 713962167 [class path: BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/}:] - dcl:BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 713962167 [class path: BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/}:] - dcl:BaseClassLoader at 223e0d14{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossweb.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 333633399 [class path: BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/}:] - dcl:BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 333633399 [class path: BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/}:] - dcl:BaseClassLoader at 1d94a7ec{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/jbossws.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1523167932 [class path: BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/}:] - dcl:BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1523167932 [class path: BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/}:] - dcl:BaseClassLoader at 67646de5{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deployers/webbeans.deployer/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,881 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 2115856113 [class path: BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/}:] - dcl:BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 2115856113 [class path: BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/}:] - dcl:BaseClassLoader at 70b85020{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/jbossweb.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1129291007 [class path: BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/}:] - dcl:BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1129291007 [class path: BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/}:] - dcl:BaseClassLoader at 3deacfda{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/snmp-adaptor.sar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1614726683 [class path: BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/}:] - dcl:BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 1614726683 [class path: BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/}:] - dcl:BaseClassLoader at 313a6b9{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/profileservice-secured.jar/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] found [B in null
> 2009-06-04 09:17:50,882 TRACE [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain] (main) [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain] get cached or create [B from pool parent - no parent pool
> 2009-06-04 09:17:50,883 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] attempt to load locally [B
> 2009-06-04 09:17:50,883 TRACE [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool] (main) [org.jboss.aop.classpool.jbosscl.JBossClDelegatingClassPool at 584939487 [class path: BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/}:] - dcl:BaseClassLoader at 738dd1b3{vfsfile:/home/mikel/local/jboss-5.1.0.GA/server/was/deploy/was.ear/} domain: [org.jboss.aop.classpool.jbosscl.JBossClClassPoolDomain at 5746b158 name:DefaultDomain]] loaded locally [B null
> 2009-06-04 09:17:50,883 ERROR [STDERR] (main) javassist.CannotCompileException: by javassist.bytecode.BadBytecode: cannot find [B
> 2009-06-04 09:17:50,928 ERROR [STDERR] (main) Caused by: javassist.bytecode.BadBytecode: cannot find [B
> The same app hosted by jboss-5.0.1.GA doesn't have this problem nor does compiling with AopC.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 13:24:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 4 Jun 2009 13:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-127) Release JBoss
 Identity Federation Stack 1.0.0.alpha3
Message-ID: <14162180.1244136296332.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release JBoss Identity Federation Stack 1.0.0.alpha3
----------------------------------------------------

                 Key: JBID-127
                 URL: https://jira.jboss.org/jira/browse/JBID-127
             Project: JBoss Identity
          Issue Type: Task
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.alpha3




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 15:42:08 2009
From: jira-events at lists.jboss.org (Praveen Palaniswamy (JIRA))
Date: Thu, 4 Jun 2009 15:42:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6011) Comments on
 Installation and Getting Started Guide
In-Reply-To: <26862617.1222830261125.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21179206.1244144528223.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470697#action_12470697 ] 

Praveen Palaniswamy commented on JBAS-6011:
-------------------------------------------

There are two binary distributions available: 
jboss-5.0.0.CR2.zip 
jboss-5.0.0.CR2-jdk6.zip 


Whats the main differences with them or add info on which flavor to choose and why

> Comments on Installation and Getting Started Guide 
> ---------------------------------------------------
>
>                 Key: JBAS-6011
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6011
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Docs/Installation and Getting Started Guide
>    Affects Versions: JBossAS-5.0.0.CR2
>            Reporter: Shelly McGowan
>            Assignee: Samson Kittoli
>
> Section 1.1 PreRequisites
> The wiki reference:
> Refer to http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossOperatingSystemSpecificIssues 
> refers to issues with Linux 2.6 kernels and installation of JBoss AS 3.x on a MainFrame.
> This reference should be removed.  
> Section 1.1.1 Hardware and Operating System Requirements
> This section refers to "supported" OS/JVM/DB combinations.  There is no support offered for the community release.
> Section 1.1.2:  Configuring your Java Environment
> Both JDK5 and JDK6 can be used with JBoss AS 5.  Please add JDK 6 to this section. 
> Chapter 2 - Installation Alternatives
> Binary Files Download
> ADD
> (extracted from release notes) JBossAS 5.0.0  can be compiled with both Java5 & Java6. The Java5 compiled binary is our primary/recommended binary 
> distribution. It has undergone rigorous testing and can run under both a Java 5 and a Java 6 runtime. When running 
> under Java 6 you need to manually copy the following libraries from the JBOSS_HOME/client directory to the 
> JBOSS_HOME/lib/endorsed directory, so that the JAX-WS 2.0 apis supported by JBossWS are used:
>     * jbossws-native-saaj.jar
>     * jbossws-native-jaxrpc.jar
>     * jbossws-native-jaxws.jar
>     * jbossws-native-jaxws-ext.jar
> The other option is to download the jdk6 distribution (jboss-5.0.0.CR2-jdk6.zip) in which case no configuration 
> changes are required.   
> Refer to the release notes for additional information about running with JDK 6.
> Correct the following:
> "Four types of server configurations will be included in your installation -  minimal  ,  default  , and  all  . The Getting Started Guide explains in detail the different server configuration file sets." to refer to only Three server configurations.  Instead of the reference to the Getting Started Guide (this guide), refer to the section that discusses this topic.
> Section 3.1 Download and Installation
> Replace references to jboss-4.2.2 to jboss-5.0.0
> There are two binary distributions available:
> jboss-5.0.0.CR2.zip
> jboss-5.0.0.CR2-jdk6.zip
> Source File Download
> ANT and mvn are  included with the JBoss distribution in <installdir>/tools/ so the downloading this section of ANT should be removed.
> 4.3 Building with Ant
> [from release notes: If you are building JBossAS from source you'll notice we are migrating to a maven2 build. At this point the build is 
> a hybrid one because it declares all JBoss dependencies as maven2 artifacts, however after the dependencies are 
> resolved/imported the legacy ant based build is used to compile and build the distribution. This will change to a 
> full maven build at some point in time. The jboss maven repo can be found here. Starting from AS5 CR2, please note 
> how the -sources.jar are also downloaded.] Revisit this section for GA for any build changes.
> Add note: When JBossAS 5 is compiled with Java 6, support for the extended JDBC 4 API is included in the binary, however 
> this can only be used under a Java 6 runtime. 
> Correct the following:
>  The JBoss Application Server files are built under the build/jboss-5.0.0.<release> directory 
> they are built under:
> build/output/jboss-5.0.0.<release>
> Chapter 7 - Check your Installation
> Correct the following:
>  To test your installation, move to JBOSS_DIST/jboss-as/bin
> to
> move to JBOSS_DIST/jboss-5.0.0.<release>/bin
> Remove the NOTE that there is no "Server Started" message.  That only pertains to the production config distributed with EAP.
> Update or remove the reference to refer to "Refer to the Getting Started Guide" to the section that discusses the server layout.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 16:15:08 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 4 Jun 2009 16:15:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-90) Add
 @ManagementProperty.readOnly
 annotations for all new properties of JBossASServerConfig
Message-ID: <3923544.1244146508610.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add @ManagementProperty.readOnly annotations for all new properties of JBossASServerConfig
------------------------------------------------------------------------------------------

                 Key: JBBOOT-90
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-90
             Project: JBoss Bootstrap
          Issue Type: Feature Request
          Components: impl-as
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger


Will be available to be exposed/read by JON/consoles

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 16:23:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 4 Jun 2009 16:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-95) JCA/SJC
Message-ID: <10386832.1244147036462.JavaMail.jira@cloud.prod.atl2.jboss.com>

JCA/SJC
-------

                 Key: JBJCA-95
                 URL: https://jira.jboss.org/jira/browse/JBJCA-95
             Project: JBoss JCA
          Issue Type: Task
          Components: Core
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha1


A simple container.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 16:35:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 4 Jun 2009 16:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2111) In-Pattern
 RestrictionConnectiveDescrs (&& and ||) do not support bindings and
 restrictions at the same time
In-Reply-To: <27444468.1244126997455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20759189.1244147756791.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2111.
----------------------------------

    Resolution: Done


Fixed.

> In-Pattern RestrictionConnectiveDescrs (&& and ||) do not support bindings and restrictions at the same time
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2111
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2111
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.0.0.M3,  5.0.0.M4, 5.0.0.M5, 5.0.0.CR1, 5.0.0.FINAL, 5.0.1.FINAL
>         Environment: any
>            Reporter: Davide Sottara
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.1.0.M1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> when trying to use connectives with restrictions and bindings, as in :
>        Type( $f1: field1 op1 expr1 && $f2 : field2 op2 expr2)
> the fieldRestrictions are ignored by the parser and only the bindings are retained.
> Thus, reading the values of $f1 or $f2 returns the right value, but the restrictions
> (field op expr) are not generated

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 17:02:56 2009
From: jira-events at lists.jboss.org (wallace njoroge (JIRA))
Date: Thu, 4 Jun 2009 17:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7000) issues when starting
 jboss server using Linux centos 5.3
In-Reply-To: <6401897.1244067776524.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22768383.1244149376617.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

wallace njoroge closed JBAS-7000.
---------------------------------

    Fix Version/s: JBossAS-5.1.0.GA
       Resolution: Done


This was a user error.  I followed the instructions below and built JBoss using src and it ended up working.

http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Installation_And_Getting_Started_Guide/5/html/source_installation.html


Thanks.

> issues when starting jboss server using Linux centos 5.3
> --------------------------------------------------------
>
>                 Key: JBAS-7000
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7000
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX/Web Console
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: wallace njoroge
>            Assignee: Darran Lofthouse
>             Fix For: JBossAS-5.1.0.GA
>
>
> Environment:
> Centos 5.3  running in VM
> Linux  2.6.18-128.1.10.el5 #1 i686 i686 i386 GNU/Linux
> java version "1.6.0_13"
> Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
> Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)
> Steps.
> 1. $ pwd
> /usr/local/jboss/bin
> 2. run.sh 
> pdadmin at PDPERFAppLnx01 bin]$ ./run.sh
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /usr/local/jboss
>   JAVA: /home/centosadmin/jdk1.6.0_13/bin/java
>   JAVA_OPTS: -Dprogram.name=run.sh -server -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true
>   CLASSPATH: /usr/local/jboss/bin/run.jar:/home/centosadmin/jdk1.6.0_13/lib/tools.jar
> =========================================================================
> 15:14:42,090 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 15:14:42,091 INFO  [ServerImpl] Release ID: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)
> 15:14:42,092 INFO  [ServerImpl] Bootstrap URL: null
> 15:14:42,092 INFO  [ServerImpl] Home Dir: /usr/local/jboss
> 15:14:42,092 INFO  [ServerImpl] Home URL: file:/usr/local/jboss/
> 15:14:42,092 INFO  [ServerImpl] Library URL: file:/usr/local/jboss/lib/
> 15:14:42,093 INFO  [ServerImpl] Patch URL: null
> 15:14:42,093 INFO  [ServerImpl] Common Base URL: file:/usr/local/jboss/common/
> 15:14:42,094 INFO  [ServerImpl] Common Library URL: file:/usr/local/jboss/common/lib/
> 15:14:42,094 INFO  [ServerImpl] Server Name: default
> 15:14:42,094 INFO  [ServerImpl] Server Base Dir: /usr/local/jboss/server
> 15:14:42,094 INFO  [ServerImpl] Server Base URL: file:/usr/local/jboss/server/
> 15:14:42,095 INFO  [ServerImpl] Server Config URL: file:/usr/local/jboss/server/default/conf/
> 15:14:42,095 INFO  [ServerImpl] Server Home Dir: /usr/local/jboss/server/default
> 15:14:42,095 INFO  [ServerImpl] Server Home URL: file:/usr/local/jboss/server/default/
> 15:14:42,095 INFO  [ServerImpl] Server Data Dir: /usr/local/jboss/server/default/data
> 15:14:42,096 INFO  [ServerImpl] Server Library URL: file:/usr/local/jboss/server/default/lib/
> 15:14:42,096 INFO  [ServerImpl] Server Log Dir: /usr/local/jboss/server/default/log
> 15:14:42,096 INFO  [ServerImpl] Server Native Dir: /usr/local/jboss/server/default/tmp/native
> 15:14:42,096 INFO  [ServerImpl] Server Temp Dir: /usr/local/jboss/server/default/tmp
> 15:14:42,097 INFO  [ServerImpl] Server Temp Deploy Dir: /usr/local/jboss/server/default/tmp/deploy
> 15:14:42,975 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/usr/local/jboss/server/default/conf/bootstrap.xml
> 15:14:43,586 INFO  [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.plugins.cache.CombinedVFSCache]
> 15:14:43,589 INFO  [VFSCacheFactory] Using VFSCache [CombinedVFSCache[real-cache: null]]
> 15:14:43,940 INFO  [CopyMechanism] VFS temp dir: /usr/local/jboss/server/default/tmp
> 15:14:43,941 INFO  [ZipEntryContext] VFS force nested jars copy-mode is enabled.
> 15:14:45,822 INFO  [ServerInfo] Java version: 1.6.0_13,Sun Microsystems Inc.
> 15:14:45,822 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
> 15:14:45,823 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Server VM 11.3-b02,Sun Microsystems Inc.
> 15:14:45,823 INFO  [ServerInfo] OS-System: Linux 2.6.18-128.1.10.el5,i386
> 15:14:45,824 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/usr/local/jboss/lib/endorsed
> 15:14:45,905 INFO  [JMXKernel] Legacy JMX core initialized
> 15:14:49,308 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 487fb7[domain=default, server=default, name=default]
> 15:14:50,731 ERROR [AbstractKernelController] Error installing to Parse: name=vfsfile:/usr/local/jboss/server/default/conf/jboss-service.xml state=Not Installed mode=Manual requiredState=Parse
> org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfsfile:/usr/local/jboss/server/default/conf/jboss-service.xml
>         at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:362)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:322)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:294)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.deploy(AbstractParsingDeployerWithOutput.java:234)
>         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.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.jbos
> Expected.
> Should work
> Error:
> Error creating managed object for vfsfile:/usr/local/jboss/server/default/conf/jboss-service.xml

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 17:11:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 4 Jun 2009 17:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16982694.1244149916579.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470717#action_12470717 ] 

Brian Stansberry commented on JBAS-6808:
----------------------------------------

Accessing the HAPartition MOs:

There can be more than one HAPartition deployed in an AS, so we use the partitionName property as the MO's name, i.e.

   @ManagementProperty(use={ViewUse.CONFIGURATION}, description="The partition's name")
   @ManagementObjectID(type="HAPartition")
   public String getPartitionName()
   {
      return this.partitionName;
   }

So, you can't just look up the HAPartition ManagedComponent via some fixed name. Instead, use the ComponentType:

ManagementView mgtView = getManagementView(); 
ComponentType type = new ComponentType("MCBean", "HAPartition");
Set<ManagedComponent> hapartitions = mgtView.getComponentsForType(type);
for (ManagedComponent mc : hapartitions)
{
   System.out.println("Partition name is " + mc.getProperty("partitionName");
}

> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 17:58:56 2009
From: jira-events at lists.jboss.org (Tom Murphy (JIRA))
Date: Thu, 4 Jun 2009 17:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2113) NPE thrown by
 LeftTuple.get() method
Message-ID: <32437267.1244152736613.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE thrown by LeftTuple.get() method
------------------------------------

                 Key: JBRULES-2113
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2113
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.0.CR1
         Environment: FOund in 5.0.0.CR1 - Community version. Windows XP
            Reporter: Tom Murphy
            Assignee: Mark Proctor


the get() method on LeftTuple throws a null exception under certain circumstances, which are as yet undetermined.
Here is the Code:

public InternalFactHandle get(final int index) {
        LeftTuple entry = this;
        while ( entry.index != index ) {
            entry = entry.parent;
        }
        return entry.handle;
    }

Note that the loop moves to each parent in succession, but never checks for entry != null. If it does get to the end of the chain, it will throw an NPE

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 19:20:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 4 Jun 2009 19:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6625) EJB 1.x or 2.x
	metrics
In-Reply-To: <7034128.1237195628874.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8127137.1244157656556.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470728#action_12470728 ] 

Jason T. Greene commented on JBAS-6625:
---------------------------------------

This has been fully implemented in the EAP5 branch. See the JMXMappingUnitTestCase:

Set<ManagedComponent> comps = mgtView.getComponentsForType(new ComponentType("EJB", "StatefulSession"));
      for (ManagedComponent comp : comps)
      {
         System.out.println(comp.getName());
         ManagedProperty property = comp.getProperty("DetypedInvocationStatistics");
         if ("jboss.j2ee:jndiName=ejb/StatefulCounterEjb,service=EJB".equals(comp.getName()))
         {
            MetaValue value = property.getValue();
            System.out.println("Value = " + value);
            CompositeValue methodStatsMap = (CompositeValue)((CompositeValue) value).get("methodStats");
            CompositeValue methodStats = (CompositeValue)methodStatsMap.get("count");
            assertEquals(2L, ((SimpleValue)methodStats.get("count")).getValue());
            return;
         }
      }

      fail("Could not find EJB!");

> EJB 1.x or 2.x metrics
> ----------------------
>
>                 Key: JBAS-6625
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6625
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB2, Management services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> EJB 1.x or 2.x Stateless Session Bean metrics (in addition to availability)
>            <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=StatelessSessionBean -->
>            <metric displayName="Create Calls"
>                    property="{stats.createCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Remove Calls"
>                    property="{stats.removeCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Method-Ready Beans"
>                    property="{stats.methodReadyCount.current}"
>                    displayType="summary"/>
>            <metric displayName="Pool Size"
>                    property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}CurrentSize}"/>
>            <metric displayName="Max Pool Size"
>                    property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}MaxSize}"/> 
> Plus the complex method invocation metrics 
>  <metric property="stats" dataType="calltime" units="milliseconds"
>                     defaultOn="false" defaultInterval="600000" destinationType="Method Name"
>                     description="the minimum, maximum, and average invocation times for each of the methods exposed by this EJB"/>
> EJB 1.x or 2.x Stateful Session Bean metrics (in addition to avail):
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=StatefulSessionBean -->
>            <metric displayName="Create Calls"
>                    description="Number of creates executed since the last time this EJB's stats were reset"
>                    property="{stats.createCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Remove Calls"
>                    description="Number of removes since the last time this EJB's stats were reset"
>                    property="{stats.removeCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Method-Ready Beans"
>                    description="The count of beans in the method-ready state"
>                    property="{stats.methodReadyCount.current}"
>                    displayType="summary"/>
>            <metric displayName="Passive Beans"
>                    description="The count of beans in the passivated state"
>                    property="{stats.passiveCount.current}"
>                    displayType="summary"/> 
> EJB 1.x or 2.x Entity Bean metrics (in addition to availability)
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=EntityBean -->
>      <metric displayName="Create Calls"
>               property="{stats.createCount.count}"
>               displayType="summary"
>               measurementType="trendsup"/>
>       <metric displayName="Remove Calls"
>               property="{stats.removeCount.count}"
>               displayType="summary"
>               measurementType="trendsup"/>
>       <metric displayName="Method-Ready Beans"
>               property="{stats.methodReadyCount.current}"
>               displayType="summary"/>
>       <metric displayName="Pooled Beans"
>               property="{stats.pooledCount.current}"
>               displayType="summary"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=cache,service=EJB}CacheSize}"
>                displayName="Cache Size"
>                defaultOn="true"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=cache,service=EJB}PassivatedCount}"
>                displayName="Passivated Count"
>                defaultOn="true"
>                measurementType="trendsup"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}PoolSize}"
>                displayName="Current Size"
>                defaultOn="true"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}MaxPoolSize}"
>                displayName="Max Size"
>                defaultOn="true"/>
> EJB 1.x or 2.x Message Driven Bean metrics (in addition to availability)
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=MessageDrivenBean -->
> <metric displayName="Create Calls"
> property="{stats.createCount.count}"
> displayType="summary"
> measurementType="trendsup"/>
> <metric displayName="Remove Calls"
> property="{stats.removeCount.count}"
> displayType="summary"
> measurementType="trendsup"/>
> <metric displayName="Method-Ready Beans"
> property="{stats.messageCount.count}"
> displayType="summary"
>               measurementType="trendsup"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 19:24:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 4 Jun 2009 19:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6625) EJB 1.x or 2.x
	metrics
In-Reply-To: <7034128.1237195628874.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30826944.1244157896566.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene resolved JBAS-6625.
-----------------------------------

    Resolution: Done


Reopen if we are missing something here

> EJB 1.x or 2.x metrics
> ----------------------
>
>                 Key: JBAS-6625
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6625
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB2, Management services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> EJB 1.x or 2.x Stateless Session Bean metrics (in addition to availability)
>            <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=StatelessSessionBean -->
>            <metric displayName="Create Calls"
>                    property="{stats.createCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Remove Calls"
>                    property="{stats.removeCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Method-Ready Beans"
>                    property="{stats.methodReadyCount.current}"
>                    displayType="summary"/>
>            <metric displayName="Pool Size"
>                    property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}CurrentSize}"/>
>            <metric displayName="Max Pool Size"
>                    property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}MaxSize}"/> 
> Plus the complex method invocation metrics 
>  <metric property="stats" dataType="calltime" units="milliseconds"
>                     defaultOn="false" defaultInterval="600000" destinationType="Method Name"
>                     description="the minimum, maximum, and average invocation times for each of the methods exposed by this EJB"/>
> EJB 1.x or 2.x Stateful Session Bean metrics (in addition to avail):
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=StatefulSessionBean -->
>            <metric displayName="Create Calls"
>                    description="Number of creates executed since the last time this EJB's stats were reset"
>                    property="{stats.createCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Remove Calls"
>                    description="Number of removes since the last time this EJB's stats were reset"
>                    property="{stats.removeCount.count}"
>                    displayType="summary"
>                    measurementType="trendsup"/>
>            <metric displayName="Method-Ready Beans"
>                    description="The count of beans in the method-ready state"
>                    property="{stats.methodReadyCount.current}"
>                    displayType="summary"/>
>            <metric displayName="Passive Beans"
>                    description="The count of beans in the passivated state"
>                    property="{stats.passiveCount.current}"
>                    displayType="summary"/> 
> EJB 1.x or 2.x Entity Bean metrics (in addition to availability)
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=EntityBean -->
>      <metric displayName="Create Calls"
>               property="{stats.createCount.count}"
>               displayType="summary"
>               measurementType="trendsup"/>
>       <metric displayName="Remove Calls"
>               property="{stats.removeCount.count}"
>               displayType="summary"
>               measurementType="trendsup"/>
>       <metric displayName="Method-Ready Beans"
>               property="{stats.methodReadyCount.current}"
>               displayType="summary"/>
>       <metric displayName="Pooled Beans"
>               property="{stats.pooledCount.current}"
>               displayType="summary"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=cache,service=EJB}CacheSize}"
>                displayName="Cache Size"
>                defaultOn="true"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=cache,service=EJB}PassivatedCount}"
>                displayName="Passivated Count"
>                defaultOn="true"
>                measurementType="trendsup"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}PoolSize}"
>                displayName="Current Size"
>                defaultOn="true"/>
>        <metric property="{{jboss.j2ee:jndiName=%name%,plugin=pool,service=EJB}MaxPoolSize}"
>                displayName="Max Size"
>                defaultOn="true"/>
> EJB 1.x or 2.x Message Driven Bean metrics (in addition to availability)
> <!-- jboss.management.local:name=%name%,J2EEServer=Local,J2EEApplication=%j2eeApplication%,EJBModule=%ejbJar%,j2eeType=MessageDrivenBean -->
> <metric displayName="Create Calls"
> property="{stats.createCount.count}"
> displayType="summary"
> measurementType="trendsup"/>
> <metric displayName="Remove Calls"
> property="{stats.removeCount.count}"
> displayType="summary"
> measurementType="trendsup"/>
> <metric displayName="Method-Ready Beans"
> property="{stats.messageCount.count}"
> displayType="summary"
>               measurementType="trendsup"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 19:30:56 2009
From: jira-events at lists.jboss.org (Ronn C (JIRA))
Date: Thu, 4 Jun 2009 19:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Admin Join problem
 -GMS flush by coordinator failed
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3258381.1244158256577.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470732#action_12470732 ] 

Ronn C commented on JGRP-985:
-----------------------------

Hi Vladimir,

No reason why UNICAST was commented out. I was trying different settings. My original problem would have UNICAST entry.

We do implement state in our real application but in the test case I didn't need to.

I agree that it is hard to replicate on 2.8.0alpha3 (compare to 2.6.3) and I did spend a whole afternoon constantly  at it and thought it was fixed. The next morning I turned up to work tried it a few times and it happened again. 

Besides all of that, are you able to confirm that this is an old problem that 2.8.0alpha3 had specifically addressed? and if it has been ported to 2.6.10.merge? We need to deploy to prod very soon and I'm hesitant to use library that is still in alpha version but if it is not a known issue and has not been fixed in 2.6.10.merge then I need to know.

> Admin  Join problem -GMS flush by coordinator failed
> ----------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 19:33:07 2009
From: jira-events at lists.jboss.org (Ronn C (JIRA))
Date: Thu, 4 Jun 2009 19:33:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Admin Join problem
 -GMS flush by coordinator failed
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11758357.1244158387645.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470734#action_12470734 ] 

Ronn C commented on JGRP-985:
-----------------------------

BTW: I run this test on a linux redhat machine. Have not tried to replicate this on Windows.

> Admin  Join problem -GMS flush by coordinator failed
> ----------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun  4 23:58:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 4 Jun 2009 23:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Work started: (JBPORTAL-2186) Extraction
 of the WSRP component to only rely on JBoss Portlet Container.
In-Reply-To: <31759938.1223021601206.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17727898.1244174336834.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on JBPORTAL-2186 started by Chris Laprun.

> Extraction of the WSRP component to only rely on JBoss Portlet Container.
> -------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2186
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2186
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.7.0 CR1 
>            Reporter: Lionel ROSIER
>            Assignee: Chris Laprun
>            Priority: Optional
>
> I need to make remote portlets without  rely on the entire portal application.
> I have one Jboss AS running with my portal, and i have others JBoss AS running with business applications and portlets.
> I would like to have the minimum stuff with portal-wsrp component and portlet container to make it works in my "business" JBoss servers.
> thank you

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 01:17:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 5 Jun 2009 01:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1638) Ordering
 Group messages delivery is not correctly handled after XA prepare()
In-Reply-To: <19894567.1244130236527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17295793.1244179076536.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470749#action_12470749 ] 

Howard Gao commented on JBMESSAGING-1638:
-----------------------------------------

The cause of this problem is that in JBM XA processing, the acknowledgement of the messages in XA transactions happens at prepare() stage, not commit() stage. And the ordering group unlocks a message based on acknowledgement. So after prepare, next message will be delivered.



> Ordering Group messages delivery is not correctly handled after XA prepare() 
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1638
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1638
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In XA environment, if one ordering group message is received within a transaction but not committed, the next message can't be received. The problem is that after the transaction is prepared, the next message is delivered, thus breaking the ordering.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 03:00:57 2009
From: jira-events at lists.jboss.org (maruthi pramod (JIRA))
Date: Fri, 5 Jun 2009 03:00:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-352) unable to generate
 process image in jpdl4
Message-ID: <14071258.1244185257421.JavaMail.jira@cloud.prod.atl2.jboss.com>

unable to generate process image in jpdl4
-----------------------------------------

                 Key: GPD-352
                 URL: https://jira.jboss.org/jira/browse/GPD-352
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM jPDL Designer 4.0.0.beta1
         Environment: windows xp
            Reporter: maruthi pramod
            Assignee: Koen Aers


Hi,
I am new to jbpm and we started R & D no jbpm4 beta version currently.i have requirement that i need to show the user by highlight the active state of the process .i am using jpdl4 1.0.0 beta version. but am unable to view or generate the image for process definitions for the new process definations or the for the examples provide by jbpm 4 beta version. and one more thing that i also unable to see the process image in GWT-console also . please provide some help on this issue.


Thanks & regards 
maruthi

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 04:57:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 5 Jun 2009 04:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1845)
 CancelAsyncTestCase is hanging
In-Reply-To: <11422647.1244192276453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6444659.1244192276739.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated EJBTHREE-1845:
------------------------------------

    Attachment: org.jboss.ejb3.async.impl.test.cancel.unit.CancelAsyncTaskTestCase-output.txt


> CancelAsyncTestCase is hanging
> ------------------------------
>
>                 Key: EJBTHREE-1845
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1845
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>            Priority: Critical
>         Attachments: org.jboss.ejb3.async.impl.test.cancel.unit.CancelAsyncTaskTestCase-output.txt
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 04:57:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 5 Jun 2009 04:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1845)
 CancelAsyncTestCase is hanging
Message-ID: <11422647.1244192276453.JavaMail.jira@cloud.prod.atl2.jboss.com>

CancelAsyncTestCase is hanging
------------------------------

                 Key: EJBTHREE-1845
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1845
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Carlo de Wolf
            Priority: Critical
         Attachments: org.jboss.ejb3.async.impl.test.cancel.unit.CancelAsyncTaskTestCase-output.txt



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 05:24:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 5 Jun 2009 05:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1844) Retry operations
 after an EJBTransactionRolledbackException
In-Reply-To: <16255062.1244128029237.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21370852.1244193896569.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated EJBTHREE-1844:
------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235567


> Retry operations after an EJBTransactionRolledbackException
> -----------------------------------------------------------
>
>                 Key: EJBTHREE-1844
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1844
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: transactions
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>
> By either annotating a bean or its methods, the applicable methods will retry the operation if an EJBTransactionRolledbackException occurs.
> @TransactionRetry(numRetries=4, waitTime=1, waitTimeUnit=TimeUnit.SECONDS)
> numRetries specifies how many times an operation will be tried.
> waitTime specified the amount of time to wait before retrying with the unit of time specified in waitTimeUnit.
> Default is 3 retries and 1000 milliseconds wait time after an EJBTransactionRolledbackException.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 05:45:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 5 Jun 2009 05:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1841) Improve logging
 for InterceptorsFactory warning
In-Reply-To: <17265944.1243955516468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25916363.1244195156538.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1841:
--------------------------------------

    Assignee: jaikiran pai


> Improve logging for InterceptorsFactory warning
> -----------------------------------------------
>
>                 Key: EJBTHREE-1841
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1841
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: AS 5.0.0.CR1
>         Environment: Windows XP 32-bit, JBoss AS 5.1.0GA
>            Reporter: Ben Abernathy
>            Assignee: jaikiran pai
>
> Every time this section of code is called, the following warning is displayed:
> 09:02:34,655 WARN  [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
> Upon inspecting EJBTHREE-1246, it appears this warning can be ignored by bean developers. If that is the case, is it necessary to fill up the console and log with benign warnings? There can be lots of these if the application is large.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 08:09:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 5 Jun 2009 08:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1640)
 ClientSessionFactory are
 garbage collected while the sessions are used in the integration tests
Message-ID: <21551780.1244203796542.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClientSessionFactory are garbage collected while the sessions are used in the integration tests
-----------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1640
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1640
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Jeff Mesnil
            Assignee: Tim Fox
             Fix For: 2.0.0.CR1


The client session impl does not have a ref on the factory which was used to create it.

In the integration-tests (e.g. ClientConsumerCloseTest),  there are a lot of:

protected void setUp() throws Exception
{
   ClientSessionFactory sf = new ClientSessionFactoryImpl(new TransportConfiguration(InVMConnectorFactory.class.getName()));
   ... 
   session = sf.createSession(false, true, true);
   session.createQueue(address, queue, false);
}

In that case, the sf variable will be GC'ed while the session field is still used which could lead to problems.

The factory *must not* be GC'ed while it still has sessions. To prevent that in all case, we can add a reference to the factory
in the created sessions.

For the integration-tests, we must also ensure that the sf is properly closed by making the sf a field and call close() in the
teardown methods.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 08:12:07 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Fri, 5 Jun 2009 08:12:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2114) Drools hangs with
 deadlock
 after it has initialized a rule (in multithreaded environment)
Message-ID: <30331207.1244203927899.JavaMail.jira@cloud.prod.atl2.jboss.com>

Drools hangs with deadlock after it has initialized a rule (in multithreaded environment)
-----------------------------------------------------------------------------------------

                 Key: JBRULES-2114
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2114
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 4.0.6
            Reporter: Andrey Nechaev
            Assignee: Mark Proctor
            Priority: Critical


Here is a scenario when drools core hangs with a deadlock:
Suppose we heve a rule throwing an exception in the RHS. 
So, if:
1. Thread A updates the Rule Base with the rule 
2. The rule fires (current thread is Thread A)
3. Rule's RHS throws an exception (still having Thread A as current)
4. Thread B tries to update the Rule Base or the Working Memory (for example, the Thread B inserts a fact)
in such a case the Thread B falls into infinite wait() loop.
Here is the test case showing such a behavior:

package com.test;

import java.io.StringReader;

import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.WorkingMemory;
import org.drools.compiler.PackageBuilder;

public class DroolsTest2 {
	private final static String rule = "" + 
	"package test\n" +
	"import com.test.DroolsTest2;\n" +
	"rule test\n" +
		"\twhen\n" +
		"\tthen\n" +
			"\t\tDroolsTest2.fail();" +
	"end";
	
	private static Object sem = new Object();
	private static boolean seed = false;
	
	public static void main(String[] args) throws Exception {
		final RuleBase rb = RuleBaseFactory.newRuleBase();
		final WorkingMemory wm = rb.newStatefulSession();
		new Thread(new Runnable() {
			@Override
			public void run() {
				seed = false;
				PackageBuilder bld = new PackageBuilder();
				try {
					bld.addPackageFromDrl(new StringReader(rule));				
					rb.addPackage(bld.getPackage());
				} catch(Exception e) {					
				} finally {
					synchronized (sem) {
						seed = true;
						sem.notify();
					}
				}
			}
		}).start();
		Thread ins = new Thread(new Runnable() {
			@Override
			public void run() {
				while(!seed) {
					synchronized (sem) {
						try {
							sem.wait();
						} catch (InterruptedException e) {}
					}
				}
				wm.insert(new Object());
			}
		});
		ins.start();
		ins.join();
	}
	
	public static void fail() {
		throw new IllegalStateException("fail!");
	}
}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 08:13:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Fri, 5 Jun 2009 08:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2114) Drools hangs with
 deadlock
 after it has initialized a rule (in multithreaded environment)
In-Reply-To: <30331207.1244203927899.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18843823.1244204036841.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrey Nechaev updated JBRULES-2114:
------------------------------------

    Attachment: patch-AbstractRuleBase


Here is the patch resolving the issue. It adds missed finally{} section in the AbstractRuleBase class.

> Drools hangs with deadlock after it has initialized a rule (in multithreaded environment)
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2114
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2114
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 4.0.6
>            Reporter: Andrey Nechaev
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: patch-AbstractRuleBase
>
>
> Here is a scenario when drools core hangs with a deadlock:
> Suppose we heve a rule throwing an exception in the RHS. 
> So, if:
> 1. Thread A updates the Rule Base with the rule 
> 2. The rule fires (current thread is Thread A)
> 3. Rule's RHS throws an exception (still having Thread A as current)
> 4. Thread B tries to update the Rule Base or the Working Memory (for example, the Thread B inserts a fact)
> in such a case the Thread B falls into infinite wait() loop.
> Here is the test case showing such a behavior:
> package com.test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> public class DroolsTest2 {
> 	private final static String rule = "" + 
> 	"package test\n" +
> 	"import com.test.DroolsTest2;\n" +
> 	"rule test\n" +
> 		"\twhen\n" +
> 		"\tthen\n" +
> 			"\t\tDroolsTest2.fail();" +
> 	"end";
> 	
> 	private static Object sem = new Object();
> 	private static boolean seed = false;
> 	
> 	public static void main(String[] args) throws Exception {
> 		final RuleBase rb = RuleBaseFactory.newRuleBase();
> 		final WorkingMemory wm = rb.newStatefulSession();
> 		new Thread(new Runnable() {
> 			@Override
> 			public void run() {
> 				seed = false;
> 				PackageBuilder bld = new PackageBuilder();
> 				try {
> 					bld.addPackageFromDrl(new StringReader(rule));				
> 					rb.addPackage(bld.getPackage());
> 				} catch(Exception e) {					
> 				} finally {
> 					synchronized (sem) {
> 						seed = true;
> 						sem.notify();
> 					}
> 				}
> 			}
> 		}).start();
> 		Thread ins = new Thread(new Runnable() {
> 			@Override
> 			public void run() {
> 				while(!seed) {
> 					synchronized (sem) {
> 						try {
> 							sem.wait();
> 						} catch (InterruptedException e) {}
> 					}
> 				}
> 				wm.insert(new Object());
> 			}
> 		});
> 		ins.start();
> 		ins.join();
> 	}
> 	
> 	public static void fail() {
> 		throw new IllegalStateException("fail!");
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 08:23:08 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 5 Jun 2009 08:23:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1638) Ordering Group
 messages delivery is not correctly handled after XA prepare()
In-Reply-To: <19894567.1244130236527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3780515.1244204588055.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1638.
-----------------------------------

    Resolution: Done


done.

Moved the ordering group control to the InMemoryCallback.afterCommit().


> Ordering Group messages delivery is not correctly handled after XA prepare() 
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1638
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1638
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In XA environment, if one ordering group message is received within a transaction but not committed, the next message can't be received. The problem is that after the transaction is prepared, the next message is delivered, thus breaking the ordering.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 08:51:21 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 5 Jun 2009 08:51:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1842)
 ClusteredIsLocalInterceptor finds unstarted beans
In-Reply-To: <10481921.1244040566021.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21284551.1244206281556.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated EJBTHREE-1842:
---------------------------------------



> ClusteredIsLocalInterceptor finds unstarted beans
> -------------------------------------------------
>
>                 Key: EJBTHREE-1842
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1842
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: interceptors
>    Affects Versions: AS 4.2.2.GA
>            Reporter: Brian Stansberry
>            Assignee: Paul Ferraro
>
> ClusteredIsLocalInterceptor determines whether a bean is available locally by checking the Ejb3Registry. Problem is beans are registered early in the deployment process, before they are started.
> In the related forum thread pawel.wyrwinski reports how this particularly causes problems when an @Depends("jboss.ha:service=HASingletonDeployer,type=Barrier") annotation is used to make a bean act as an HASingleton. The bean is included in the Ejb3Registry on all nodes but is only started on one.
> A logically obvious solution would be to check whether the target container is started before invoking locally. Unfortunately, AFAICT Container and its subclasses do not expose any method to support such a check.
> Pawel reported this against 4.2.2 so that the "Affects Version" I used, but a quick code check leads me to believe it still exists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 09:53:10 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Fri, 5 Jun 2009 09:53:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6720) Make sure that the
 metrics for
 Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as
 ViewUse.STATISTIC
In-Reply-To: <7508166.1238615242987.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25753540.1244209998990.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka updated JBAS-6720:
-------------------------------

    Environment: 
JBoss AS Branch_5_x r86586, embjopr r266

EmbJopr TS: testQueueMetrics

  was:JBoss AS Branch_5_x r86586, embjopr r266



> Make sure that the metrics for Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as ViewUse.STATISTIC
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6720
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6720
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: JBoss AS Branch_5_x r86586, embjopr r266
> EmbJopr TS: testQueueMetrics
>            Reporter: Farah Juma
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Steps to reproduce:
> Create a new Topic or Queue using Embedded Jopr. Send some messages to the Topic or Queue. Navigate to the "Metrics" tab for the resource. The metrics do not get updated to reflect this change. All the values are 0.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Fri Jun  5 10:39:15 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 10:39:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1845)
 CancelAsyncTestCase is hanging
In-Reply-To: <11422647.1244192276453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23588413.1244212755953.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger reassigned EJBTHREE-1845:
---------------------------------------------

    Assignee: Andrew Lee Rubinger


> CancelAsyncTestCase is hanging
> ------------------------------
>
>                 Key: EJBTHREE-1845
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1845
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>         Attachments: org.jboss.ejb3.async.impl.test.cancel.unit.CancelAsyncTaskTestCase-output.txt
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 10:41:26 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 5 Jun 2009 10:41:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-203) add an option to
 validate just
 built SchemaBinding against the XSD in the default schema resolvers
In-Reply-To: <5112439.1243607876650.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18086862.1244212886642.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBXB-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470813#action_12470813 ] 

Alexey Loubyansky commented on JBXB-203:
----------------------------------------

Wiki page about the feature http://www.jboss.org/community/wiki/Bindingvalidation

> add an option to validate just built SchemaBinding against the XSD in the default schema resolvers
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBXB-203
>                 URL: https://jira.jboss.org/jira/browse/JBXB-203
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> There was a suggestion to add an option to validate the consistency of SchemaBinding instances built from JAXB/JBossXB annotations against their corresponding XSDs during schema resolution.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 11:31:36 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 5 Jun 2009 11:31:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-68) JBoss Metadata
	1.0.2.Beta1
In-Reply-To: <29947535.1236869745527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17962750.1244215896716.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-68:
---------------------------------

    Summary: JBoss Metadata 1.0.2.Beta1  (was: JBoss Metadata 1.0.0.CR18)


> JBoss Metadata 1.0.2.Beta1
> --------------------------
>
>                 Key: JBJCA-68
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-68
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha1
>
>
> Standalone + Test

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 11:53:41 2009
From: jira-events at lists.jboss.org (Matthias Lanz (JIRA))
Date: Fri, 5 Jun 2009 11:53:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1844) Retry
 operations after an EJBTransactionRolledbackException
In-Reply-To: <16255062.1244128029237.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6860298.1244217231616.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470830#action_12470830 ] 

Matthias Lanz commented on EJBTHREE-1844:
-----------------------------------------

Hi Carlo,

sounds very good, exactly what I were looking for :-)

I think this new annotation can be applied as default for all SLSB in ejb3-interceptors-aop.xml, that would be very useful.
If it can be applied to all session beans by default it would be neccessary that "numRetries=0" is a valid value, to disable retry for specific beans.

I wonder how nested session bean calls are handled. I assume this annotation can only have any effect on session bean methods that are starting a new transaction, not using one previously started from the caller?

As a extension in the future it would be nice if one could define any kind of retry-handler; an interface which can be implemented to decide on which exceptions a retry should occur.

Example:
@TransactionRetry(numRetries=4, waitTime=1, waitTimeUnit=TimeUnit.SECONDS, retryHandler=MyPersonalOnlyDeadlockRetryHandler.class) 

and then:

public class MyPersonalOnlyDeadlockRetryHandler implements com.jboss.ejb3.RetryHandler {

  public boolean isRetryable(Exception e) {
    return (e instanceof EJBRolledbackException && e.getCause() instanceof MySqlDeadLockDetectedException);
  }


But that is really a nice-to-have, retries on every error should do no harm.



> Retry operations after an EJBTransactionRolledbackException
> -----------------------------------------------------------
>
>                 Key: EJBTHREE-1844
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1844
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: transactions
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>
> By either annotating a bean or its methods, the applicable methods will retry the operation if an EJBTransactionRolledbackException occurs.
> @TransactionRetry(numRetries=4, waitTime=1, waitTimeUnit=TimeUnit.SECONDS)
> numRetries specifies how many times an operation will be tried.
> waitTime specified the amount of time to wait before retrying with the unit of time specified in waitTimeUnit.
> Default is 3 retries and 1000 milliseconds wait time after an EJBTransactionRolledbackException.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 12:23:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 5 Jun 2009 12:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-82) Circle of trust servlet
In-Reply-To: <13620737.1240499860623.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25025382.1244219036422.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-82.
-----------------------------

    Resolution: Done


> Circle of trust servlet
> -----------------------
>
>                 Key: JBID-82
>                 URL: https://jira.jboss.org/jira/browse/JBID-82
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha2
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha3
>
>
> Circle of Trust servlet  that can be configured to pick up metadata from a set of URLs and update the common store.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 13:39:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 13:39:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-84) Missing ServerConfig
 @ManagedProperty annotations
In-Reply-To: <1654126.1243254896568.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17336346.1244223597180.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-84.
---------------------------------------

    Resolution: Done


Local tests show these now passing on 2.0.0-SNAPSHOT

> Missing ServerConfig @ManagedProperty annotations
> -------------------------------------------------
>
>                 Key: JBBOOT-84
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-84
>             Project: JBoss Bootstrap
>          Issue Type: Bug
>    Affects Versions: 0.1.2
>            Reporter: Emanuel Muckenhuber
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-alpha-1
>
>
> The BasicJBossASServerConfig is missing @ManagedProperty annotations, which causes those two tests failures: 
> > org.jboss.test.cluster.defaultcfg.profileservice.test.FarmedClusterHotDeployUnitTestCase(ClusteredProfileService).testFarmHotDeployment
> > org.jboss.test.deployers.test.DeploymentManagerUnitTestCase(profileservice).testHotDeploymentBeans 
> I assume that this ServerConfig is the one used previously (which seems to have the correct annotations):
> https://svn.jboss.org/repos/jbossas/projects/bootstrap/tags/jboss-bootstrap-1.0.0-Beta-3/src/main/java/org/jboss/bootstrap/BaseServerConfig.java

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 13:39:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 13:39:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-90) Add
 @ManagementProperty.readOnly
 annotations for all new properties of JBossASServerConfig
In-Reply-To: <3923544.1244146508610.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4509409.1244223597421.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-90.
---------------------------------------

    Fix Version/s: 2.0.0-alpha-1
       Resolution: Done


> Add @ManagementProperty.readOnly annotations for all new properties of JBossASServerConfig
> ------------------------------------------------------------------------------------------
>
>                 Key: JBBOOT-90
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-90
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-as
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-alpha-1
>
>
> Will be available to be exposed/read by JON/consoles

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 13:43:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 13:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-91) Resolve dependencies
 in preparation for 2.0.0-alpha-1 release
Message-ID: <22684076.1244223836413.JavaMail.jira@cloud.prod.atl2.jboss.com>

Resolve dependencies in preparation for 2.0.0-alpha-1 release
-------------------------------------------------------------

                 Key: JBBOOT-91
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-91
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: build, impl-as, impl-base, impl-mc, spi, spi-as, spi-mc
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 2.0.0-alpha-1


Used to track commits for upgrades in preparation for 2.0.0-alpha-1 release of:

build
spi
spi-mc
spi-as
impl-base
impl-mc
impl-as

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 14:43:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 14:43:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-85) Undeploy
 services/deployments on shutdown of server
In-Reply-To: <14639616.1243256216555.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <421026.1244227437341.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-85.
---------------------------------------

    Fix Version/s: 2.0.0-alpha-1
       Resolution: Done


> Undeploy services/deployments on shutdown of server
> ---------------------------------------------------
>
>                 Key: JBBOOT-85
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-85
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-as
>    Affects Versions: 0.1.2
>            Reporter: jaikiran pai
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-alpha-1
>
>
> Creating this task based on our email discussion:
> Updated my JBoss AS 5_x branch to see the bootstrap changes (0.1.2 of impl-as). Looks like the way shutdown is handled in AS has now changed? I did a Ctrl+C on the command prompt and the server shutdown "immidiately". In earlier versions, i remember a shutdown would trigger undeployments of various deployments. I don't see this happening anymore. Thought you might be interested in this  :)  Let me know if you need more information. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 14:43:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 14:43:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6974) Ensure the Shutdown
 Hook fully shuts down the Server
In-Reply-To: <20457385.1243304636427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27072829.1244227437110.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-6974.
---------------------------------------

    Resolution: Done


> Ensure the Shutdown Hook fully shuts down the Server
> ----------------------------------------------------
>
>                 Key: JBAS-6974
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6974
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: JBAS-6974.patch
>
>
> Shutdown Hook is not calling full shutdown before the process exits.
> For starters, there's this:
> if (currentState.equals(LifecycleState.STARTED) || currentState.equals(LifecycleState.STARTING))
> Find other possible problems and ensure the lifecycle goes through full shutdown before the VM can terminate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 14:43:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 14:43:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-91) Resolve
 dependencies in preparation for 2.0.0-alpha-1 release
In-Reply-To: <22684076.1244223836413.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19771827.1244227437519.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-91.
---------------------------------------

    Resolution: Done


> Resolve dependencies in preparation for 2.0.0-alpha-1 release
> -------------------------------------------------------------
>
>                 Key: JBBOOT-91
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-91
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: build, impl-as, impl-base, impl-mc, spi, spi-as, spi-mc
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-alpha-1
>
>
> Used to track commits for upgrades in preparation for 2.0.0-alpha-1 release of:
> build
> spi
> spi-mc
> spi-as
> impl-base
> impl-mc
> impl-as

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 15:02:01 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 15:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16626479.1244228521736.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470859#action_12470859 ] 

Andrew Lee Rubinger commented on JBAS-6808:
-------------------------------------------

Now in Branch_5_x (not yet trunk):

+++ ManagedComponent(name=jboss.system:type=ServerConfig, type=(ComponentType{type=MCBean, subtype=ServerConfig}), compName=jboss.system:type=ServerConfig, attachment: org.jboss.bootstrap.impl.as.config.BasicJBossASServerConfig
++++++ properties: [serverHomeDir, serverLogLocation, udpGroup, homeUrl, serverLogDir, serverDataLocation, homeDir, serverLibraryURL, serverDataDir, bindAddress, nativeLibraryLocation, serverName, commonBaseURL, serverHomeURL, bootstrapURL, serverTempDir, serverNativeDir, partitionName, udpPort, commonLibraryURL, serverBaseDir, serverTempLocation, serverConfLocation, bootLibraryLocation, serverBaseURL]


> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 15:03:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Fri, 5 Jun 2009 15:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2115) Changing import /
 globals not considered a change
Message-ID: <12795241.1244228636947.JavaMail.jira@cloud.prod.atl2.jboss.com>

Changing import / globals not considered a change
-------------------------------------------------

                 Key: JBRULES-2115
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2115
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse (flow)
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen
             Fix For: FUTURE


When changing the imports or globals inside the properties dialog for split constraints or the event wait constraint, the editor is not aware of these changes.  As a result, if you only change the imports or globals in your process, the editor will not pick up the change and you won't be able to save the process.

Steps:
1. Create a new rules flow file using the "RuleFlow file" wizard.
2. Add an Event Wait and an End node. Create connections between them.
3. Save the file. Open the rf file in another editor (such as vi). Analyze the structure.
4. From the event wait node's properties, open the constraints -> global section. Add "global String testStr"
5. Try to save the file, which thinks it hasn't changed. Open the rf file in another editor (such as vi). Notice that the global variable is missing from the file.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 16:24:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 16:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-92) Expose partition
 name as a @ManagementProperty
Message-ID: <80513.1244233496440.JavaMail.jira@cloud.prod.atl2.jboss.com>

Expose partition name as a @ManagementProperty
----------------------------------------------

                 Key: JBBOOT-92
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-92
             Project: JBoss Bootstrap
          Issue Type: Feature Request
          Components: legacy
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger


Requested by Brian for inclusion into EAP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 16:24:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 16:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-92) Expose partition
 name as a @ManagementProperty
In-Reply-To: <80513.1244233496440.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17088556.1244233496549.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBBOOT-92:
--------------------------------------

    Affects Version/s: 1.0.1


> Expose partition name as a @ManagementProperty
> ----------------------------------------------
>
>                 Key: JBBOOT-92
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-92
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: legacy
>    Affects Versions: 1.0.1
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>
> Requested by Brian for inclusion into EAP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 17:02:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 17:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-92) Expose partition
 name as a @ManagementProperty
In-Reply-To: <80513.1244233496440.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16502875.1244235776420.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-92.
---------------------------------------

    Fix Version/s: 1.0.1
       Resolution: Done


> Expose partition name as a @ManagementProperty
> ----------------------------------------------
>
>                 Key: JBBOOT-92
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-92
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: legacy
>    Affects Versions: 1.0.1
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.0.1
>
>
> Requested by Brian for inclusion into EAP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 17:07:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 17:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13061809.1244236076706.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470873#action_12470873 ] 

Andrew Lee Rubinger commented on JBAS-6808:
-------------------------------------------

For EAP, bring jboss-bootstrap to 1.0.1.  This should bring in JBBOOT-92.  Let me know if there are issues (legacy is much harder to test in place, and I haven't done real due diligence in supporting it as the whole impl is @Deprecated)

> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 17:11:07 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 5 Jun 2009 17:11:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21724466.1244236267599.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBAS-6808:
--------------------------------------

    Comment: was deleted


> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 17:20:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 5 Jun 2009 17:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-530) Look at using
 refids instead
 of properties to refer to thirdparty jars in the dist build.
In-Reply-To: <13279899.1243637036330.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <189575.1244236856534.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier reassigned JBBUILD-530:
---------------------------------

    Assignee: Paul Gier


> Look at using refids instead of properties to refer to thirdparty jars in the dist build.
> -----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-530
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-530
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the AS distribution build uses properties set by the maven ant tasks to access the various thirdparty dependencies.
> It might be better to use refids since this will cause the build to immediately fail when one is expected but not found.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 17:44:07 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 5 Jun 2009 17:44:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-127) Release JBoss Identity
 Federation Stack 1.0.0.alpha3
In-Reply-To: <14162180.1244136296332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25035045.1244238247751.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-127.
------------------------------

    Resolution: Done


> Release JBoss Identity Federation Stack 1.0.0.alpha3
> ----------------------------------------------------
>
>                 Key: JBID-127
>                 URL: https://jira.jboss.org/jira/browse/JBID-127
>             Project: JBoss Identity
>          Issue Type: Task
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 17:51:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 5 Jun 2009 17:51:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-530) Look at using
 refids instead of
 properties to refer to thirdparty jars in the dist build.
In-Reply-To: <13279899.1243637036330.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26031944.1244238716366.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier closed JBBUILD-530.
-----------------------------

    Resolution: Done


Fixed in trunk.

> Look at using refids instead of properties to refer to thirdparty jars in the dist build.
> -----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-530
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-530
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the AS distribution build uses properties set by the maven ant tasks to access the various thirdparty dependencies.
> It might be better to use refids since this will cause the build to immediately fail when one is expected but not found.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun  5 19:50:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Fri, 5 Jun 2009 19:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-734) Advisor does not
 treat javassist.NotFoundException
Message-ID: <26146146.1244245856689.JavaMail.jira@cloud.prod.atl2.jboss.com>

Advisor does not treat javassist.NotFoundException
--------------------------------------------------

                 Key: JBAOP-734
                 URL: https://jira.jboss.org/jira/browse/JBAOP-734
             Project: JBoss AOP
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.1.GA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: 2.2.0.GA


When using other agent-enabled tools with JBoss AOP, we may run into a class that contains a field, method, constructor or whatever that was not loaded by Javassist.
In this case, when we try to manipulate that method, constructor or field using javassist we will get a javassist.NotFoundException. Instead of throwing this exception, we need to ignore it and consider the field non-existent.

Here is a concrete scenario: when using Eclipse TPTP (http://www.eclipse.org/tptp/) to profile JBoss AS we get the following AS log:
15:05:55,390 INFO  [Server] Starting JBoss (MX MicroKernel)...
15:05:55,394 INFO  [Server] Release ID: JBoss [EAP] 4.3.0.GA_CP04 (build: SVNTag=JBPAPP_4_3_0_GA_CP04 date=200902200048)
15:05:55,396 INFO  [Server] Home Dir: /usr/local/java/jboss/as/jboss-eap-4.3/jboss-as
15:05:55,396 INFO  [Server] Home URL: file:/usr/local/java/jboss/as/jboss-eap-4.3/jboss-as/
15:05:55,397 INFO  [Server] Patch URL: null
15:05:55,397 INFO  [Server] Server Name: eapDemo
15:05:55,398 INFO  [Server] Server Home Dir: /usr/local/java/jboss/as/jboss-eap-4.3/jboss-as/server/eapDemo
15:05:55,398 INFO  [Server] Server Home URL: file:/usr/local/java/jboss/as/jboss-eap-4.3/jboss-as/server/eapDemo/
15:05:55,398 INFO  [Server] Server Log Dir: /usr/local/java/jboss/as/jboss-eap-4.3/jboss-as/server/eapDemo/log
15:05:55,398 INFO  [Server] Server Temp Dir: /usr/local/java/jboss/as/jboss-eap-4.3/jboss-as/server/eapDemo/tmp
15:05:55,398 INFO  [Server] Root Deployment Filename: jboss-service.xml
15:05:55,924 INFO  [ServerInfo] Java version: 1.5.0_16,Sun Microsystems Inc.
15:05:55,924 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_16-b02,Sun Microsystems Inc.
15:05:55,924 INFO  [ServerInfo] OS-System: Linux 2.6.18-92.1.13.el5PAE,i386
15:05:56,450 INFO  [Server] Core system initialized
15:05:59,570 INFO  [WebService] Using RMI server codebase: http://localhost:8083/
15:05:59,572 INFO  [Log4jService$URLWatchTimerTask] Configuring from URL: resource:jboss-log4j.xml
15:06:00,538 INFO  [TransactionManagerService] JBossTS Transaction Service (JTA version) - JBoss Inc.
15:06:00,538 INFO  [TransactionManagerService] Setting up property manager MBean and JMX layer
15:06:01,077 INFO  [TransactionManagerService] Starting recovery manager
15:06:01,364 INFO  [TransactionManagerService] Recovery manager started
15:06:01,365 INFO  [TransactionManagerService] Binding TransactionManager JNDI Reference
15:06:05,223 INFO  [EJB3Deployer] Starting java:comp multiplexer
15:06:09,714 INFO  [NativeServerConfig] JBoss Web Services - Native
15:06:09,715 INFO  [NativeServerConfig] jbossws-native-2.0.1.SP2_CP05 (build=200902200020)
15:06:11,014 INFO  [AprLifecycleListener] The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/local/java/jdk1.5.0_16/jre/lib/i386/server:/usr/local/java/jdk1.5.0_16/jre/lib/i386:/usr/local/java/jdk1.5.0_16/jre/../lib/i386:/usr/local/java/jboss/jbds/jbdevstudio/eclipse/plugins/org.eclipse.tptp.platform.ac.linux_ia32_4.4.100.v200902101418/agent_controller/bin:/usr/local/java/jboss/jbds/jbdevstudio/eclipse/plugins/org.eclipse.tptp.platform.ac.linux_ia32_4.4.100.v200902101418/agent_controller/lib:/usr/local/java/jboss/jbds/jbdevstudio/eclipse/plugins/org.eclipse.tptp.platform.jvmti.runtime_4.4.201.v200902180100/agent_files/linux_ia32:/usr/local/java/jboss/jbds/jbdevstudio/eclipse/plugins/org.eclipse.hyades.probekit_4.2.401.v200901290100//os/linux/x86:/usr/local/java/jdk1.5.0_16/jre/lib/i386/client:/usr/local/java/jdk1.5.0_16/jre/lib/i386:/usr/lib/xulrunner-1.9:/usr/lib/xulrunner-1.9
15:06:11,180 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-localhost%2F127.0.0.1-8080
15:06:11,180 INFO  [AjpProtocol] Initializing Coyote AJP/1.3 on ajp-localhost%2F127.0.0.1-8009
15:06:11,181 INFO  [Catalina] Initialization processed in 404 ms
15:06:11,181 INFO  [StandardService] Starting service jboss.web
15:06:11,183 INFO  [StandardEngine] Starting Servlet Engine: JBossWeb/2.0.0.GA_CP
15:06:11,293 INFO  [Catalina] Server startup in 112 ms
15:06:11,428 INFO  [TomcatDeployer] deploy, ctxPath=/, warUrl=.../deploy/jboss-web.deployer/ROOT.war/
15:06:12,353 INFO  [TomcatDeployer] deploy, ctxPath=/invoker, warUrl=.../deploy/http-invoker.sar/invoker.war/
15:06:12,704 INFO  [TomcatDeployer] deploy, ctxPath=/jbossws, warUrl=.../deploy/jbossws.sar/jbossws-context.war/
15:06:13,024 INFO  [TomcatDeployer] deploy, ctxPath=/web-console, warUrl=.../deploy/management/console-mgr.sar/web-console.war/
15:06:13,657 INFO  [MailService] Mail Service bound to java:/Mail
15:06:13,798 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-ha-local-jdbc.rar
15:06:13,831 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-ha-xa-jdbc.rar
15:06:13,855 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-local-jdbc.rar
15:06:13,878 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-xa-jdbc.rar
15:06:13,949 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jms-ra.rar
15:06:13,977 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/mail-ra.rar
15:06:14,025 INFO  [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/quartz-ra.rar
15:06:14,041 INFO  [QuartzResourceAdapter] start quartz!!!
15:06:14,170 INFO  [SimpleThreadPool] Job execution threads will use class loader of thread: main
15:06:14,260 INFO  [QuartzScheduler] Quartz Scheduler v.1.5.2 created.
15:06:14,266 INFO  [RAMJobStore] RAMJobStore initialized.
15:06:14,266 INFO  [StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
15:06:14,266 INFO  [StdSchedulerFactory] Quartz scheduler version: 1.5.2
15:06:14,266 INFO  [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
15:06:15,151 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
15:06:15,683 WARN  [SecurityMetadataStore] 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.
15:06:15,705 INFO  [ServerPeer] JBoss Messaging 1.4.0.SP3-CP07 server [0] started
15:06:16,034 ERROR [ExceptionUtil] org.jboss.jms.server.connectionfactory.ConnectionFactory at f65b5b startService
java.lang.ExceptionInInitializerError
   at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:182)
   at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:204)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy42.start(Unknown Source)
   at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:202)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy9.deploy(Unknown Source)
   at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
   at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy5.deploy(Unknown Source)
   at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
   at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
   at org.jboss.Main.boot(Main.java:200)
   at org.jboss.Main$1.run(Main.java:508)
   at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at org.jboss.aop.pointcut.FieldMatcher.visit(FieldMatcher.java:181)
   at org.jboss.aop.pointcut.ast.ASTAll.jjtAccept(ASTAll.java:41)
   at org.jboss.aop.pointcut.MatcherHelper.visit(MatcherHelper.java:88)
   at org.jboss.aop.pointcut.MatcherHelper.matches(MatcherHelper.java:83)
   at org.jboss.aop.pointcut.PointcutExpression.matchesGet(PointcutExpression.java:154)
   at org.jboss.aop.ClassAdvisor.resolveFieldPointcut(ClassAdvisor.java:431)
   at org.jboss.aop.ClassAdvisor.createInterceptorChains(ClassAdvisor.java:608)
   at org.jboss.aop.ClassAdvisor.access$300(ClassAdvisor.java:82)
   at org.jboss.aop.ClassAdvisor$1.run(ClassAdvisor.java:299)
   at java.security.AccessController.doPrivileged(Native Method)
   at org.jboss.aop.ClassAdvisor.attachClass(ClassAdvisor.java:271)
   at org.jboss.aop.AspectManager.initialiseClassAdvisor(AspectManager.java:591)
   at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:579)
   at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.<clinit>(ClientConnectionFactoryDelegate.java)
   ... 120 more
Caused by: java.lang.RuntimeException: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:405)
   at org.jboss.aop.pointcut.FieldMatcher.visit(FieldMatcher.java:177)
   ... 133 more
Caused by: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at javassist.CtClassType.getField(CtClassType.java:822)
   at org.jboss.aop.util.ReflectToJavassist.fieldToJavassist(ReflectToJavassist.java:55)
   at org.jboss.aop.annotation.PortableAnnotationElement.isAnyAnnotationPresent(PortableAnnotationElement.java:113)
   at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:401)
   ... 134 more
15:06:16,037 WARN  [ServiceController] Problem starting service jboss.messaging.connectionfactory:service=ConnectionFactory
java.lang.ExceptionInInitializerError
   at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:182)
   at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:204)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy42.start(Unknown Source)
   at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:202)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy9.deploy(Unknown Source)
   at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
   at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy5.deploy(Unknown Source)
   at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
   at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
   at org.jboss.Main.boot(Main.java:200)
   at org.jboss.Main$1.run(Main.java:508)
   at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at org.jboss.aop.pointcut.FieldMatcher.visit(FieldMatcher.java:181)
   at org.jboss.aop.pointcut.ast.ASTAll.jjtAccept(ASTAll.java:41)
   at org.jboss.aop.pointcut.MatcherHelper.visit(MatcherHelper.java:88)
   at org.jboss.aop.pointcut.MatcherHelper.matches(MatcherHelper.java:83)
   at org.jboss.aop.pointcut.PointcutExpression.matchesGet(PointcutExpression.java:154)
   at org.jboss.aop.ClassAdvisor.resolveFieldPointcut(ClassAdvisor.java:431)
   at org.jboss.aop.ClassAdvisor.createInterceptorChains(ClassAdvisor.java:608)
   at org.jboss.aop.ClassAdvisor.access$300(ClassAdvisor.java:82)
   at org.jboss.aop.ClassAdvisor$1.run(ClassAdvisor.java:299)
   at java.security.AccessController.doPrivileged(Native Method)
   at org.jboss.aop.ClassAdvisor.attachClass(ClassAdvisor.java:271)
   at org.jboss.aop.AspectManager.initialiseClassAdvisor(AspectManager.java:591)
   at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:579)
   at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.<clinit>(ClientConnectionFactoryDelegate.java)
   ... 120 more
Caused by: java.lang.RuntimeException: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:405)
   at org.jboss.aop.pointcut.FieldMatcher.visit(FieldMatcher.java:177)
   ... 133 more
Caused by: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at javassist.CtClassType.getField(CtClassType.java:822)
   at org.jboss.aop.util.ReflectToJavassist.fieldToJavassist(ReflectToJavassist.java:55)
   at org.jboss.aop.annotation.PortableAnnotationElement.isAnyAnnotationPresent(PortableAnnotationElement.java:113)
   at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:401)
   ... 134 more
15:06:16,039 INFO  [ConnectionFactoryJNDIMapper] supportsFailover attribute is true on connection factory: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory but post office is non clustered. So connection factory will *not* support failover
15:06:16,039 INFO  [ConnectionFactoryJNDIMapper] supportsLoadBalancing attribute is true on connection factory: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory but post office is non clustered. So connection factory will *not* support load balancing
15:06:16,039 ERROR [ExceptionUtil] org.jboss.jms.server.connectionfactory.ConnectionFactory at 11e1813 startService
java.lang.NoClassDefFoundError
   at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:182)
   at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:204)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy42.start(Unknown Source)
   at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:202)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy9.deploy(Unknown Source)
   at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
   at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy5.deploy(Unknown Source)
   at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
   at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
   at org.jboss.Main.boot(Main.java:200)
   at org.jboss.Main$1.run(Main.java:508)
   at java.lang.Thread.run(Thread.java:595)
15:06:16,040 WARN  [ServiceController] Problem starting service jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
java.lang.NoClassDefFoundError
   at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:182)
   at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:204)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy42.start(Unknown Source)
   at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:202)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy9.deploy(Unknown Source)
   at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
   at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy5.deploy(Unknown Source)
   at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
   at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
   at org.jboss.Main.boot(Main.java:200)
   at org.jboss.Main$1.run(Main.java:508)
   at java.lang.Thread.run(Thread.java:595)
15:06:16,041 ERROR [ExceptionUtil] org.jboss.jms.server.connectionfactory.ConnectionFactory at be9340 startService
java.lang.NoClassDefFoundError
   at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:182)
   at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:204)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy42.start(Unknown Source)
   at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:202)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy9.deploy(Unknown Source)
   at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
   at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy5.deploy(Unknown Source)
   at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
   at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
   at org.jboss.Main.boot(Main.java:200)
   at org.jboss.Main$1.run(Main.java:508)
   at java.lang.Thread.run(Thread.java:595)
15:06:16,042 WARN  [ServiceController] Problem starting service jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
java.lang.NoClassDefFoundError
   at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:182)
   at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:204)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at org.jboss.system.ServiceController.start(ServiceController.java:435)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy42.start(Unknown Source)
   at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:202)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy9.deploy(Unknown Source)
   at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
   at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
   at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
   at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
   at $Proxy0.start(Unknown Source)
   at org.jboss.system.ServiceController.start(ServiceController.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
   at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
   at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy4.start(Unknown Source)
   at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
   at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
   at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
   at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
   at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
   at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
   at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
   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:659)
   at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
   at $Proxy5.deploy(Unknown Source)
   at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
   at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
   at org.jboss.Main.boot(Main.java:200)
   at org.jboss.Main$1.run(Main.java:508)
   at java.lang.Thread.run(Thread.java:595)
15:06:16,062 INFO  [QueueService] Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,063 INFO  [QueueService] Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,066 INFO  [TopicService] Topic[/topic/testTopic] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,130 INFO  [TopicService] Topic[/topic/securedTopic] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,132 INFO  [TopicService] Topic[/topic/testDurableTopic] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,148 INFO  [QueueService] Queue[/queue/testQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,182 INFO  [QueueService] Queue[/queue/A] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,185 INFO  [QueueService] Queue[/queue/B] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,187 INFO  [QueueService] Queue[/queue/C] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,189 INFO  [QueueService] Queue[/queue/D] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,191 INFO  [QueueService] Queue[/queue/ex] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,193 INFO  [QueueService] Queue[/queue/PrivateDLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,194 INFO  [QueueService] Queue[/queue/PrivateExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,208 INFO  [QueueService] Queue[/queue/QueueWithOwnDLQAndExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,209 INFO  [TopicService] Topic[/topic/TopicWithOwnDLQAndExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,211 INFO  [QueueService] Queue[/queue/QueueWithOwnRedeliveryDelay] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,212 INFO  [TopicService] Topic[/topic/TopicWithOwnRedeliveryDelay] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,214 INFO  [QueueService] Queue[/queue/testDistributedQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,215 INFO  [TopicService] Topic[/topic/testDistributedTopic] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:06:16,598 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
15:06:16,625 INFO  [TomcatDeployer] deploy, ctxPath=/jmx-console, warUrl=.../deploy/jmx-console.war/
15:06:16,791 ERROR [URLDeploymentScanner] Incomplete Deployment listing:

--- MBeans waiting for other MBeans ---
ObjectName: jboss.messaging.connectionfactory:service=ConnectionFactory
 State: FAILED
 Reason: java.lang.ExceptionInInitializerError
 I Depend On:
   jboss.messaging:service=ServerPeer
   jboss.messaging:service=Connector,transport=bisocket
   jboss.messaging:service=PostOffice

ObjectName: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
 State: FAILED
 Reason: java.lang.NoClassDefFoundError
 I Depend On:
   jboss.messaging:service=ServerPeer
   jboss.messaging:service=Connector,transport=bisocket
   jboss.messaging:service=PostOffice

ObjectName: jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
 State: FAILED
 Reason: java.lang.NoClassDefFoundError
 I Depend On:
   jboss.messaging:service=ServerPeer
   jboss.messaging:service=Connector,transport=bisocket
   jboss.messaging:service=PostOffice

--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.messaging.connectionfactory:service=ConnectionFactory
 State: FAILED
 Reason: java.lang.ExceptionInInitializerError
 I Depend On:
   jboss.messaging:service=ServerPeer
   jboss.messaging:service=Connector,transport=bisocket
   jboss.messaging:service=PostOffice

ObjectName: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
 State: FAILED
 Reason: java.lang.NoClassDefFoundError
 I Depend On:
   jboss.messaging:service=ServerPeer
   jboss.messaging:service=Connector,transport=bisocket
   jboss.messaging:service=PostOffice

ObjectName: jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
 State: FAILED
 Reason: java.lang.NoClassDefFoundError
 I Depend On:
   jboss.messaging:service=ServerPeer
   jboss.messaging:service=Connector,transport=bisocket
   jboss.messaging:service=PostOffice


15:06:17,043 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-localhost%2F127.0.0.1-8080
15:06:17,066 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-localhost%2F127.0.0.1-8009
15:06:17,074 INFO  [Server] JBoss (MX MicroKernel) [4.3.0.GA_CP04 (build: SVNTag=JBPAPP_4_3_0_GA_CP04 date=200902200048)] Started in 21s:672ms
15:06:27,192 ERROR [MessagingXAResourceWrapper] ********************************Failed to connect to server
javax.naming.NameNotFoundException: XAConnectionFactory not bound
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:581)
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:589)
   at org.jnp.server.NamingServer.getObject(NamingServer.java:595)
   at org.jnp.server.NamingServer.lookup(NamingServer.java:342)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
   at javax.naming.InitialContext.lookup(InitialContext.java:351)
   at org.jboss.util.naming.Util.lookup(Util.java:215)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getConnectionFactory(MessagingXAResourceWrapper.java:354)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.connect(MessagingXAResourceWrapper.java:300)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:259)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.recover(MessagingXAResourceWrapper.java:107)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:746)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:685)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)
15:06:27,199 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException: Error trying to connect to provider java:/DefaultJMSProvider, XAException.XAER_RMERR
15:06:27,199 ERROR [MessagingXAResourceWrapper] ********************************Failed to connect to server
javax.naming.NameNotFoundException: XAConnectionFactory not bound
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:581)
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:589)
   at org.jnp.server.NamingServer.getObject(NamingServer.java:595)
   at org.jnp.server.NamingServer.lookup(NamingServer.java:342)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
   at javax.naming.InitialContext.lookup(InitialContext.java:351)
   at org.jboss.util.naming.Util.lookup(Util.java:215)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getConnectionFactory(MessagingXAResourceWrapper.java:354)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.connect(MessagingXAResourceWrapper.java:300)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:259)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.recover(MessagingXAResourceWrapper.java:107)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:771)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:685)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)
15:08:37,265 ERROR [MessagingXAResourceWrapper] ********************************Failed to connect to server
javax.naming.NameNotFoundException: XAConnectionFactory not bound
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:581)
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:589)
   at org.jnp.server.NamingServer.getObject(NamingServer.java:595)
   at org.jnp.server.NamingServer.lookup(NamingServer.java:342)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
   at javax.naming.InitialContext.lookup(InitialContext.java:351)
   at org.jboss.util.naming.Util.lookup(Util.java:215)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getConnectionFactory(MessagingXAResourceWrapper.java:354)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.connect(MessagingXAResourceWrapper.java:300)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:259)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.recover(MessagingXAResourceWrapper.java:107)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:746)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:685)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)
15:08:37,269 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException: Error trying to connect to provider java:/DefaultJMSProvider, XAException.XAER_RMERR
15:08:37,271 ERROR [MessagingXAResourceWrapper] ********************************Failed to connect to server
javax.naming.NameNotFoundException: XAConnectionFactory not bound
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:581)
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:589)
   at org.jnp.server.NamingServer.getObject(NamingServer.java:595)
   at org.jnp.server.NamingServer.lookup(NamingServer.java:342)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
   at javax.naming.InitialContext.lookup(InitialContext.java:351)
   at org.jboss.util.naming.Util.lookup(Util.java:215)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getConnectionFactory(MessagingXAResourceWrapper.java:354)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.connect(MessagingXAResourceWrapper.java:300)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:259)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.recover(MessagingXAResourceWrapper.java:107)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:771)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:685)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)
15:10:47,343 ERROR [MessagingXAResourceWrapper] ********************************Failed to connect to server
javax.naming.NameNotFoundException: XAConnectionFactory not bound
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:581)
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:589)
   at org.jnp.server.NamingServer.getObject(NamingServer.java:595)
   at org.jnp.server.NamingServer.lookup(NamingServer.java:342)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
   at javax.naming.InitialContext.lookup(InitialContext.java:351)
   at org.jboss.util.naming.Util.lookup(Util.java:215)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getConnectionFactory(MessagingXAResourceWrapper.java:354)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.connect(MessagingXAResourceWrapper.java:300)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:259)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.recover(MessagingXAResourceWrapper.java:107)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:746)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:685)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)
15:10:47,347 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException: Error trying to connect to provider java:/DefaultJMSProvider, XAException.XAER_RMERR
15:10:47,348 ERROR [MessagingXAResourceWrapper] ********************************Failed to connect to server
javax.naming.NameNotFoundException: XAConnectionFactory not bound
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:581)
   at org.jnp.server.NamingServer.getBinding(NamingServer.java:589)
   at org.jnp.server.NamingServer.getObject(NamingServer.java:595)
   at org.jnp.server.NamingServer.lookup(NamingServer.java:342)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
   at javax.naming.InitialContext.lookup(InitialContext.java:351)
   at org.jboss.util.naming.Util.lookup(Util.java:215)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getConnectionFactory(MessagingXAResourceWrapper.java:354)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.connect(MessagingXAResourceWrapper.java:300)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.getDelegate(MessagingXAResourceWrapper.java:259)
   at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.recover(MessagingXAResourceWrapper.java:107)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:771)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:685)
   at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
   at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)



The central point of this log is the stack trace:

Caused by: java.lang.RuntimeException: java.lang.RuntimeException: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at org.jboss.aop.pointcut.FieldMatcher.visit(FieldMatcher.java:181)
   at org.jboss.aop.pointcut.ast.ASTAll.jjtAccept(ASTAll.java:41)
   at org.jboss.aop.pointcut.MatcherHelper.visit(MatcherHelper.java:88)
   at org.jboss.aop.pointcut.MatcherHelper.matches(MatcherHelper.java:83)
   at org.jboss.aop.pointcut.PointcutExpression.matchesGet(PointcutExpression.java:154)
   at org.jboss.aop.ClassAdvisor.resolveFieldPointcut(ClassAdvisor.java:431)
   at org.jboss.aop.ClassAdvisor.createInterceptorChains(ClassAdvisor.java:608)
   at org.jboss.aop.ClassAdvisor.access$300(ClassAdvisor.java:82)
   at org.jboss.aop.ClassAdvisor$1.run(ClassAdvisor.java:299)
   at java.security.AccessController.doPrivileged(Native Method)
   at org.jboss.aop.ClassAdvisor.attachClass(ClassAdvisor.java:271)
   at org.jboss.aop.AspectManager.initialiseClassAdvisor(AspectManager.java:591)
   at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:579)
   at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.<clinit>(ClientConnectionFactoryDelegate.java)
   ... 120 more
Caused by: java.lang.RuntimeException: javassist.NotFoundException: field: sm_bAlreadyInvoked116423 in org.jboss.jms.client.delegate.DelegateSupport
   at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:405)
   at org.jboss.aop.pointcut.FieldMatcher.visit(FieldMatcher.java:177)
   ... 133 more 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 04:21:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 8 Jun 2009 04:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7001) Create a stand-alone
 JBossWeb integration project
Message-ID: <4203295.1244449316600.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create a stand-alone JBossWeb integration project
-------------------------------------------------

                 Key: JBAS-7001
                 URL: https://jira.jboss.org/jira/browse/JBAS-7001
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf


Create a stand-alone integration implementation of Tomcat and VDF usable in AS, Embedded and other runtimes based on Bootstrap.

The working title is 'Spider'.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 04:24:01 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Mon, 8 Jun 2009 04:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6937) Bad deployment scan
	order?
In-Reply-To: <23627422.1242664685223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <808154.1244449441761.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved JBAS-6937.
---------------------------------------

    Resolution: Out of Date


This does not seem to be an issue any more, at least i can't reproduce it. In case you still see  problems feel free to reopen and update the description.

> Bad deployment scan order?
> --------------------------
>
>                 Key: JBAS-6937
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6937
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers, ProfileService
>            Reporter: Ondrej ?i?ka
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: EARwithWAR-handmade.zip
>
>
> Steps to reproduce:
> 1) Download attached EARwithWAR-handmade.zip and unzip
> 2) Hot-deploy the contained directory - EARwithWAR-handmade
> 3) Check the deployment info (in EmbJopr)  - a WAR contained inside appears
> 4) In the deploy dir, add '.ear' to the name of 'EARwithWAR-handmade' - rename to 'EARwithWAR-handmade.ear'
> 5) Now check the deployment info in EmbJopr. You will see:
>    - the WAR is DOWN
>   - new EAR appeared, but is also  down
> 6) After invoking the Start op on EAR, everything gets to the right state.
> (18:14:46) ozizka: emuckenhuber: I've noticed one interesting thing. AS 5 deployment scanner first scans what's new and then what was removed. Shouldn't it be the opposite way?
> (18:20:34) emuckenhuber: ozizka: well it first scans for removal and then for additions - where do you see that ?
> (18:20:47) ozizka: I've tried it this way:
> (18:21:18) ozizka: It scans recursively, so I've created an exploded ear directory, only without the .ear suffix.
> (18:21:28) ozizka: So AS scanned, found the .war inside this dir,
> (18:21:34) ozizka: and deployed it.
> (18:21:49) ozizka: Then I renamed the directory - added the .ear suffix,
> (18:22:01) ozizka: so what should happen IMO is first undeploying WAR,
> (18:22:11) ozizka: and then deploying newly found exploded EAR
> (18:22:24) ozizka: I know it's not usual use case :)
> (18:22:45) ozizka: But instead, the WAR is reported to be DOWN (in EmbJopr)
> (18:23:15) ozizka: and ear appears, but is DOWN too
> (18:24:22) ozizka: When I invoke the Start operation on the ear, everything gets to normal, that is, EAR UP, standalone WAR disappears and Embedded WAR appears and is UP
> 18:25
> (18:26:02) ozizka: emuckenhuber: And to add why I think that deployment is done first is this:
> (18:26:02) ozizka: java.lang.IllegalStateException: jboss.web.deployment:war=/hellothere-inEAR is already installed.
> (18:26:19) ozizka: that happens after the rename

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun  8 04:52:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 8 Jun 2009 04:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1536) Optimisation
In-Reply-To: <9922377.1236104062518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5593556.1244451176451.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated JBMESSAGING-1536:
-------------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0 Beta)


> Optimisation
> ------------
>
>                 Key: JBMESSAGING-1536
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1536
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0.CR1
>
>
> Various system optimisations:
> 1) Optimise message routing. We can probably combine preroute and route. Also in BindingsImpl we can  avoid creation of so many sets, and use array based logic instead.
> 2) Optimise SimpleString - intern() where appropriate
> 3) Optimise journal direct byte buffers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 06:02:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 8 Jun 2009 06:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-203) add an option to
 validate just
 built SchemaBinding against the XSD in the default schema resolvers
In-Reply-To: <5112439.1243607876650.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18509705.1244455376692.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBXB-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBXB-203.
----------------------------------

    Resolution: Done


Done.

> add an option to validate just built SchemaBinding against the XSD in the default schema resolvers
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBXB-203
>                 URL: https://jira.jboss.org/jira/browse/JBXB-203
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> There was a suggestion to add an option to validate the consistency of SchemaBinding instances built from JAXB/JBossXB annotations against their corresponding XSDs during schema resolution.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 06:19:56 2009
From: jira-events at lists.jboss.org (sarfaraz khan (JIRA))
Date: Mon, 8 Jun 2009 06:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7002) Cannot release
 inactive sessions in oracle
Message-ID: <16823614.1244456396481.JavaMail.jira@cloud.prod.atl2.jboss.com>

Cannot release inactive sessions in oracle 
-------------------------------------------

                 Key: JBAS-7002
                 URL: https://jira.jboss.org/jira/browse/JBAS-7002
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.0.GA
         Environment: RedHat Enterprise Linux AS 
            Reporter: sarfaraz khan
            Priority: Critical


My application is running in jboss .
when ever i execute a query from my application to database a session is created in oracle in ACTIVE mode.
Then after some time is it converted to INACTIVE mode
if my application runs more than 3 hours then more than 130 INACTIVE session created in oracle.

if i close the jboss then there is no INACTIVE session available.
so it is clear that JBOSS is not releasing connections.

my orcle-ds.xml is like this

<datasources>
	<local-tx-datasource>

		<jndi-name>cseDS</jndi-name>
		<use-java-context>false</use-java-context>
		<connection-url>jdbc:oracle:thin:@172.20.6.184:1531:csesrvcm</connection-url>
		<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
		<user-name>auditdba</user-name>
		<password>abcd1234</password>
		<min-pool-size>5</min-pool-size>
		<max-pool-size>50</max-pool-size>
		<idle-timeout-minutes>3</idle-timeout-minutes>

	</local-tx-datasource>
</datasources>


Please suggest me how to realease all inactive sessions in database.

it is an critical issue.my application is in production server .. please help me  ???

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 06:57:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Mon, 8 Jun 2009 06:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (RELOADED-8) Create a JSR-250
 compliant injection framework on top of VDF
In-Reply-To: <3377495.1242033106555.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7412885.1244458676737.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/RELOADED-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470961#action_12470961 ] 

Richard Opalka commented on RELOADED-8:
---------------------------------------

I'm little bit confused:( Will this issue address only JSR-250 spec. or injection in general?

> Create a JSR-250 compliant injection framework on top of VDF
> ------------------------------------------------------------
>
>                 Key: RELOADED-8
>                 URL: https://jira.jboss.org/jira/browse/RELOADED-8
>             Project: JBoss Reloaded
>          Issue Type: Feature Request
>          Components: injection
>    Affects Versions: injection-0.1.0
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 06:59:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Mon, 8 Jun 2009 06:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (RELOADED-8) Create a JSR-250
 compliant injection framework on top of VDF
In-Reply-To: <3377495.1242033106555.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14001318.1244458796930.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/RELOADED-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470962#action_12470962 ] 

Richard Opalka commented on RELOADED-8:
---------------------------------------

Identified JBossWS Project Injection Requirements:

JSR-250 - Common Java Annotations for Java Platform

JSR-244 - Java Platform, Enterprise Edition (a.k.a. Java EE 5)
 - Chapter 5.2.3 - Annotations and Injection

I identified injection related sections from JBossWS project perspective:
JSR-224 - The Java API for XML Web Services (a.k.a JAX-WS 2.1)
 - Chapter 5.2.1 - Endpoint Usage
 - Chapter 5.3 - javax.xml.ws.WebServiceContext
 - Chapter 7.9 - javax.xml.ws.WebServiceRef
 - Chapter 7.10 - javax.xml.ws.WebServiceRefs
 - Chapter 9.3.1 - Handler Lifecycle

https://jira.jboss.org/jira/browse/JBWS-2634
 - although not explicitly specified in any of the above specs
   we implemented the @EJB injection support in JBossWS components.
   This feature is required from JSR-244 -> Chapter 5.2.3 -> Table EE.5-1 (IOHO)

I'd put these requirements to associated jboss-dev thread, but forums seem to be unfunctional now.

> Create a JSR-250 compliant injection framework on top of VDF
> ------------------------------------------------------------
>
>                 Key: RELOADED-8
>                 URL: https://jira.jboss.org/jira/browse/RELOADED-8
>             Project: JBoss Reloaded
>          Issue Type: Feature Request
>          Components: injection
>    Affects Versions: injection-0.1.0
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 07:03:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Mon, 8 Jun 2009 07:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (RELOADED-8) Create a JSR-250
 compliant injection framework on top of VDF
In-Reply-To: <3377495.1242033106555.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14895757.1244459037006.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/RELOADED-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated RELOADED-8:
----------------------------------

    Comment: was deleted


> Create a JSR-250 compliant injection framework on top of VDF
> ------------------------------------------------------------
>
>                 Key: RELOADED-8
>                 URL: https://jira.jboss.org/jira/browse/RELOADED-8
>             Project: JBoss Reloaded
>          Issue Type: Feature Request
>          Components: injection
>    Affects Versions: injection-0.1.0
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 07:03:57 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Mon, 8 Jun 2009 07:03:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (RELOADED-8) Create a JSR-250
 compliant injection framework on top of VDF
In-Reply-To: <3377495.1242033106555.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23021613.1244459037910.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/RELOADED-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated RELOADED-8:
----------------------------------

    Comment: was deleted


> Create a JSR-250 compliant injection framework on top of VDF
> ------------------------------------------------------------
>
>                 Key: RELOADED-8
>                 URL: https://jira.jboss.org/jira/browse/RELOADED-8
>             Project: JBoss Reloaded
>          Issue Type: Feature Request
>          Components: injection
>    Affects Versions: injection-0.1.0
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 07:03:57 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Mon, 8 Jun 2009 07:03:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (RELOADED-8) Create a JSR-250
 compliant injection framework on top of VDF
In-Reply-To: <3377495.1242033106555.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31650864.1244459037426.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/RELOADED-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12470963#action_12470963 ] 

Richard Opalka commented on RELOADED-8:
---------------------------------------

Identified JBossWS Project Injection Requirements:

JSR-244 - Java Platform, Enterprise Edition (a.k.a. Java EE 5)
 - Chapter 5.2.3 - Annotations and Injection

JSR-224 - The Java API for XML Web Services (a.k.a JAX-WS 2.1)
 - Chapter 5.2.1 - Endpoint Usage
 - Chapter 5.3 - javax.xml.ws.WebServiceContext
 - Chapter 7.9 - javax.xml.ws.WebServiceRef
 - Chapter 7.10 - javax.xml.ws.WebServiceRefs
 - Chapter 9.3.1 - Handler Lifecycle

https://jira.jboss.org/jira/browse/JBWS-2634
 - although not explicitly specified in any of the above specs
   we implemented the @EJB injection support in JBossWS components.
   This feature is required from JSR-244 -> Chapter 5.2.3 -> Table EE.5-1 (IOHO)

I'd put these requirements to associated jboss-dev thread, but forums seem to be unfunctional now. 


> Create a JSR-250 compliant injection framework on top of VDF
> ------------------------------------------------------------
>
>                 Key: RELOADED-8
>                 URL: https://jira.jboss.org/jira/browse/RELOADED-8
>             Project: JBoss Reloaded
>          Issue Type: Feature Request
>          Components: injection
>    Affects Versions: injection-0.1.0
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 07:31:56 2009
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Mon, 8 Jun 2009 07:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7002) Cannot release
 inactive sessions in oracle
In-Reply-To: <16823614.1244456396481.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9963294.1244460716471.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Brock closed JBAS-7002.
------------------------------

    Resolution: Rejected


Use the forums to ask to help.


> Cannot release inactive sessions in oracle 
> -------------------------------------------
>
>                 Key: JBAS-7002
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7002
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.0.GA
>         Environment: RedHat Enterprise Linux AS 
>            Reporter: sarfaraz khan
>            Priority: Critical
>
> My application is running in jboss .
> when ever i execute a query from my application to database a session is created in oracle in ACTIVE mode.
> Then after some time is it converted to INACTIVE mode
> if my application runs more than 3 hours then more than 130 INACTIVE session created in oracle.
> if i close the jboss then there is no INACTIVE session available.
> so it is clear that JBOSS is not releasing connections.
> my orcle-ds.xml is like this
> <datasources>
> 	<local-tx-datasource>
> 		<jndi-name>cseDS</jndi-name>
> 		<use-java-context>false</use-java-context>
> 		<connection-url>jdbc:oracle:thin:@172.20.6.184:1531:csesrvcm</connection-url>
> 		<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
> 		<user-name>auditdba</user-name>
> 		<password>abcd1234</password>
> 		<min-pool-size>5</min-pool-size>
> 		<max-pool-size>50</max-pool-size>
> 		<idle-timeout-minutes>3</idle-timeout-minutes>
> 	</local-tx-datasource>
> </datasources>
> Please suggest me how to realease all inactive sessions in database.
> it is an critical issue.my application is in production server .. please help me  ???

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 09:30:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Mon, 8 Jun 2009 09:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2116) Drools core throws
 OutOfMemoryException
Message-ID: <21984599.1244467856662.JavaMail.jira@cloud.prod.atl2.jboss.com>

Drools core throws OutOfMemoryException
---------------------------------------

                 Key: JBRULES-2116
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2116
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 4.0.7
            Reporter: Andrey Nechaev
            Assignee: Mark Proctor


In some situations, Drools' tuple hash tables become corrupted, as they have loops in a list elements. It causes an infinite loop in the TupleHashTable's resize() method. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 09:32:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Mon, 8 Jun 2009 09:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2116) Drools core throws
 OutOfMemoryException
In-Reply-To: <21984599.1244467856662.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23652495.1244467976528.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrey Nechaev updated JBRULES-2116:
------------------------------------

    Attachment: patch-TupleHashTable


Attachement is the patch for TupleHashTable class. It prevents using lists as a hash table's element. This is not theoptimal solution but it works with some performance and memory consumption degradation.

> Drools core throws OutOfMemoryException
> ---------------------------------------
>
>                 Key: JBRULES-2116
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2116
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 4.0.7
>            Reporter: Andrey Nechaev
>            Assignee: Mark Proctor
>         Attachments: patch-TupleHashTable
>
>
> In some situations, Drools' tuple hash tables become corrupted, as they have loops in a list elements. It causes an infinite loop in the TupleHashTable's resize() method. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 09:54:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 8 Jun 2009 09:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7003) Jopr does not start
	in Branch_5_x
Message-ID: <8325659.1244469296878.JavaMail.jira@cloud.prod.atl2.jboss.com>

Jopr does not start in Branch_5_x
---------------------------------

                 Key: JBAS-7003
                 URL: https://jira.jboss.org/jira/browse/JBAS-7003
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-5.2.0.Beta1


Container task to track any problems relating to Jopr not starting in AS Branch_5_x.

Any runtime/deploytime failures need a corresponding testcase.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 09:58:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 8 Jun 2009 09:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-93) Define
 @ManagementProperty ServerConfig.getSpecificationVersion
Message-ID: <19526088.1244469536566.JavaMail.jira@cloud.prod.atl2.jboss.com>

Define @ManagementProperty ServerConfig.getSpecificationVersion
---------------------------------------------------------------

                 Key: JBBOOT-93
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-93
             Project: JBoss Bootstrap
          Issue Type: Feature Request
          Components: impl-as
    Affects Versions: 2.0.0-alpha-1
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 2.0.0-alpha-2


This is required by Jopr.

09:32:48,964 WARN  [InventoryManager] Failure during discovery for [JBossAS Server] Resources - failed after 6282 ms.
java.lang.Exception: Discovery component invocation failed.
        at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:248)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
        at java.util.concurrent.FutureTask.run(FutureTask.java:123)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalStateException: Property named 'specificationVersion' not found for ManagedComponent [org.jboss.managed.plugins.ManagedComponentImpl at 24b80637{name=jboss.system:type=ServerConfig, type=ComponentType{type=MCBean, subtype=ServerConfig}, owner=ManagedDeployment at 1381870081}].
        at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSimplePropertyValue(ManagedComponentUtils.java:73)
        at org.rhq.plugins.jbossas5.ApplicationServerDiscoveryComponent.discoverInProcessJBossAS(ApplicationServerDiscoveryComponent.java:281)
        at org.rhq.plugins.jbossas5.ApplicationServerDiscoveryComponent.discoverResources(ApplicationServerDiscoveryComponent.java:102)
        at sun.reflect.GeneratedMethodAccessor311.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
        ... 5 more

Legacy has:

ctor:
serverSpecificationVersion = thisPackage.getSpecificationVersion();

@ManagementProperty(description="the server Specification-Version",
         use={ViewUse.STATISTIC})
   public String getSpecificationVersion()
   {
      return serverSpecificationVersion;
   }

Remove the STATISTIC use and mark read-only.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 10:17:00 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 8 Jun 2009 10:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2738) Security Auditing
	Service
Message-ID: <8546865.1244470620842.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471014#action_12471014 ] 

Anil Saldhana commented on JBAS-2738:
-------------------------------------

http://server.dzone.com/articles/security-auditing-jboss

> Security Auditing Service
> -------------------------
>
>                 Key: JBAS-2738
>                 URL: https://jira.jboss.org/jira/browse/JBAS-2738
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.0.Beta1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.0.0.Beta1
>
>
> A Security Audit Service needs to be implemented that can provide audit logs for various security related customer needs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 10:25:09 2009
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Mon, 8 Jun 2009 10:25:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-189)
 setRequiredStage() does not work
Message-ID: <8854106.1244471109455.JavaMail.jira@cloud.prod.atl2.jboss.com>

setRequiredStage() does not work
--------------------------------

                 Key: JBDEPLOY-189
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-189
             Project: JBoss Deployers
          Issue Type: Bug
          Components: deployer
    Affects Versions: JBDEPLOY-2.0.7.GA, JBDEPLOY-2.0.6.GA
            Reporter: Adrian Brock
            Assignee: Adrian Brock


The feature added in JBDEPLOY-170 does not work and has no tests.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 10:26:57 2009
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Mon, 8 Jun 2009 10:26:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBDEPLOY-189) setRequiredStage()
 does not work
In-Reply-To: <8854106.1244471109455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22030320.1244471217850.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Brock closed JBDEPLOY-189.
---------------------------------

    Fix Version/s:  JBDEPLOY-2.2.x
                   JBDEPLOY-2.0.8.GA
       Resolution: Done


> setRequiredStage() does not work
> --------------------------------
>
>                 Key: JBDEPLOY-189
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-189
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.6.GA, JBDEPLOY-2.0.7.GA
>            Reporter: Adrian Brock
>            Assignee: Adrian Brock
>             Fix For:  JBDEPLOY-2.2.x, JBDEPLOY-2.0.8.GA
>
>
> The feature added in JBDEPLOY-170 does not work and has no tests.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 10:56:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 8 Jun 2009 10:56:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1641) Stopping the
 bridge service doesn't stop the failure handler
Message-ID: <31429260.1244473017316.JavaMail.jira@cloud.prod.atl2.jboss.com>

Stopping the bridge service doesn't stop the failure handler
------------------------------------------------------------

                 Key: JBMESSAGING-1641
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1641
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.4.GA, 1.4.0.SP3.CP08
            Reporter: Howard Gao
            Assignee: Howard Gao
             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA


when bridge is stopped via the JMX, the stop() action doesn't stop the failure handler, which will keep trying to reconnect even after bridge service has been stopped.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 11:12:56 2009
From: jira-events at lists.jboss.org (Zachary Bedell (JIRA))
Date: Mon, 8 Jun 2009 11:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-204) Validation errors in
 jboss_5_1.xsd
Message-ID: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>

Validation errors in jboss_5_1.xsd
----------------------------------

                 Key: JBMETA-204
                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.0.0.CR17
         Environment: Eclipse 3.4, WebToolsPlatform 3.0
            Reporter: Zachary Bedell
            Assignee: Alexey Loubyansky
            Priority: Critical
             Fix For: 1.0.1.GA


I tried to create a jboss.xml from jboss_5_1.xsd, using Eclipe/WebTools for validation. To achieve this, I picked newest "jboss_5_1.xsd" and "jboss_common_5_1.xsd"  from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/jboss-common_5_1.xsd) and added them to an eclipse web project. The files at http://www.jboss.org/j2ee/schema/ are much older and with more problems...

This results in several problems:
=================
Import of "javaee_5.xsd"  in jboss_common_5_1.xsd does not point to the web location:
<xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>

It should be:
<xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>

=================
Next one is in "jboss_5_1.xsd"

cos-nonambig: "http://www.jboss.com/xml/ns/javaee":security-identity and "http://www.jboss.com/xml/ns/javaee":security-identity (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.	jboss_5_1.xsd

Reason: Element  "security-identity" in "message-driven-beanType" is duplicate.
Same issue was resolved for jboss_5_0.xsd: https://jira.jboss.org/jira/browse/JBMETA-185

=================
jboss_5_1.xsd contains this imports:
   <xsd:include schemaLocation="jboss-common_5_1.xsd"/>

It must point to a valid url: http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd

================
And finally: the usage comment talk about "5.0" and "jboss_5_0.xsd", should be 5.1


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 11:14:56 2009
From: jira-events at lists.jboss.org (Zachary Bedell (JIRA))
Date: Mon, 8 Jun 2009 11:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-204) Validation errors in
 jboss_5_1.xsd (missing webservice-descriptionType)
In-Reply-To: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13515302.1244474096637.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Zachary Bedell updated JBMETA-204:
----------------------------------

              Summary: Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)  (was: Validation errors in jboss_5_1.xsd)
        Fix Version/s:     (was: 1.0.1.GA)
    Affects Version/s: 1.0.1.GA
                           (was: 1.0.0.CR17)
          Description: An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.  (was: I tried to create a jboss.xml from jboss_5_1.xsd, using Eclipe/WebTools for validation. To achieve this, I picked newest "jboss_5_1.xsd" and "jboss_common_5_1.xsd"  from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/jboss-common_5_1.xsd) and added them to an eclipse web project. The files at http://www.jboss.org/j2ee/schema/ are much older and with more problems...

This results in several problems:
=================
Import of "javaee_5.xsd"  in jboss_common_5_1.xsd does not point to the web location:
<xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>

It should be:
<xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>

=================
Next one is in "jboss_5_1.xsd"

cos-nonambig: "http://www.jboss.com/xml/ns/javaee":security-identity and "http://www.jboss.com/xml/ns/javaee":security-identity (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.	jboss_5_1.xsd

Reason: Element  "security-identity" in "message-driven-beanType" is duplicate.
Same issue was resolved for jboss_5_0.xsd: https://jira.jboss.org/jira/browse/JBMETA-185

=================
jboss_5_1.xsd contains this imports:
   <xsd:include schemaLocation="jboss-common_5_1.xsd"/>

It must point to a valid url: http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd

================
And finally: the usage comment talk about "5.0" and "jboss_5_0.xsd", should be 5.1
)


> Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)
> -----------------------------------------------------------------------
>
>                 Key: JBMETA-204
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Zachary Bedell
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>
> An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 11:22:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 8 Jun 2009 11:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-204) Validation errors
 in jboss_5_1.xsd (missing webservice-descriptionType)
In-Reply-To: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10076007.1244474576492.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471035#action_12471035 ] 

Alexey Loubyansky commented on JBMETA-204:
------------------------------------------

jboss:webservice-descriptionType is defined in jboss-common_5_1.xsd which is included into jboss_5_1.xsd. So, I guess the include is not being done correctly.

> Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)
> -----------------------------------------------------------------------
>
>                 Key: JBMETA-204
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Zachary Bedell
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>
> An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 11:26:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 8 Jun 2009 11:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-204) Validation errors
 in jboss_5_1.xsd (missing webservice-descriptionType)
In-Reply-To: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5647922.1244474816492.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471036#action_12471036 ] 

Alexey Loubyansky commented on JBMETA-204:
------------------------------------------

The online versions of the schemas are out of date. This is one contains webservice-descriptionType http://anonsvn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/resources/schema/jboss-common_5_1.xsd

> Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)
> -----------------------------------------------------------------------
>
>                 Key: JBMETA-204
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Zachary Bedell
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>
> An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 11:49:57 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 8 Jun 2009 11:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-414) XACML:
 ParsingException should also contain the real cause
Message-ID: <12595818.1244476197825.JavaMail.jira@cloud.prod.atl2.jboss.com>

XACML: ParsingException should also contain the real cause
----------------------------------------------------------

                 Key: SECURITY-414
                 URL: https://jira.jboss.org/jira/browse/SECURITY-414
             Project: JBoss Security and Identity Management
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-sunxacml
    Affects Versions: JBossXACML_2.0.3
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: jbossxacml_2.0.3.SP1


The Parsing Exception should also specify the real cause message as part of the exception message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 11:57:56 2009
From: jira-events at lists.jboss.org (Russ Egan (JIRA))
Date: Mon, 8 Jun 2009 11:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1603) EJB with
 dependencies upon itself fails deployment
In-Reply-To: <31197954.1227668256534.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17660666.1244476676776.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471046#action_12471046 ] 

Russ Egan commented on EJBTHREE-1603:
-------------------------------------

Note: this worked in JBoss 4.2.  It was a useful means of controlling transaction boundaries without resorting to bean-managed transactions (by having non-transactional methods exposed by one interface call transactional methods exposed by a different interface, but all implemented by the same bean/service (because maybe both functions need access to some internal shared state).

> EJB with dependencies upon itself fails deployment
> --------------------------------------------------
>
>                 Key: EJBTHREE-1603
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1603
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: Unscheduled
>
>         Attachments: EJBTHREE-1603.patch
>
>
> The following construct:
> @Stateless
> @Remote(SelfDependencyRemoteBusiness.class)
> @Local(SelfDependencyLocalBusiness.class)
> public class SelfDependencyBean implements SelfDependencyLocalBusiness, SelfDependencyRemoteBusiness
> {
>    @EJB
>    private SelfDependencyLocalBusiness local;
> ...
> }
> ...fails deployment:
> 21:55:09,828 WARN  [MainDeployer] Failed to deploy: file:/home/alrubinger/business/jboss/wc/jbossas/projects/ejb3/trunk/testsuite/target/test-lib/ejbthreexxx.jar
> org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> jboss.j2ee:jar=ejbthreexxx.jar,name=SelfDependencyBean,service=EJB3
>  -> <UNKNOWN jboss.j2ee:jar=ejbthreexxx.jar,name=SelfDependencyBean,service=EJB3>{Described:** UNRESOLVED Demands 'jndi:SelfDependencyBean/local-org.jboss.ejb3.test.ejbthreexxx.SelfDependencyLocalBusiness' **}
> *** CONTEXTS IN ERROR: Name -> Error
> <UNKNOWN jboss.j2ee:jar=ejbthreexxx.jar,name=SelfDependencyBean,service=EJB3> -> ** UNRESOLVED Demands 'jndi:SelfDependencyBean/local-org.jboss.ejb3.test.ejbthreexxx.SelfDependencyLocalBusiness' **
> This is the cause of 3 regressions in "asynchronous" tests currently

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 12:00:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 8 Jun 2009 12:00:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-414) XACML:
 ParsingException should also contain the real cause
In-Reply-To: <12595818.1244476197825.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13354769.1244476856434.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-414.
----------------------------------

    Resolution: Done


> XACML: ParsingException should also contain the real cause
> ----------------------------------------------------------
>
>                 Key: SECURITY-414
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-414
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-sunxacml
>    Affects Versions: JBossXACML_2.0.3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP1
>
>
> The Parsing Exception should also specify the real cause message as part of the exception message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 12:18:56 2009
From: jira-events at lists.jboss.org (Zachary Bedell (JIRA))
Date: Mon, 8 Jun 2009 12:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-204) Validation errors
 in jboss_5_1.xsd (missing webservice-descriptionType)
In-Reply-To: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15834392.1244477936587.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471049#action_12471049 ] 

Zachary Bedell commented on JBMETA-204:
---------------------------------------

Pulling the full 'schema' directory from svn (r89971) and adjusting all schemaLocation's to reference the pulled & locally hosted files rather than the ones on JBoss' public servers appears to have resolved this issue.

Is there any possibility of modifying the schemas to use relative schema locations rather than fully qualified URL's to public servers?  Bringing a server up in our server network fails miserably as no out-bound HTTP is allowed.  We end up hosting the files on an in-house webserver, but all of the files with literal schemaLocation elements need to be manually edited.

Thanks,
Zac

> Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)
> -----------------------------------------------------------------------
>
>                 Key: JBMETA-204
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Zachary Bedell
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>
> An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 12:36:12 2009
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Mon, 8 Jun 2009 12:36:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4893) JvmRouteValve
 (UseJK) for non session replication setup
In-Reply-To: <15617003.1193112303806.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8514433.1244478973801.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471051#action_12471051 ] 

Jean-Frederic Clere commented on JBAS-4893:
-------------------------------------------

Won't be moving the issue to the front-end makes sense. The front-end knows where it connects to and therefore knows the "new" JVMRoute.
Probably that should be switch able via a parameter in httpd. 

> JvmRouteValve (UseJK) for non session replication setup
> -------------------------------------------------------
>
>                 Key: JBAS-4893
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4893
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Takayoshi Kimura
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Currently JBoss doesn't install JvmRouteValve for non session
> replication setup. However, it's still useful in the following
> scenario:
> * 1 Apache HTTPD frontend and 2 JBoss AS instances without session replication, sticky session enabled
> * A request goes JBoss node AAA (JSESSIONID=xxx.AAA)
> * The node AAA crashed
> * The request goes node BBB, lost session, recreate another, JSESSIONID won't be changed
> * The node AAA recovered
> * The request comes back to the node AAA, lost session again
> Enabling JvmRouteValve can prevent last failure.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 12:59:56 2009
From: jira-events at lists.jboss.org (Paul Nittel (JIRA))
Date: Mon, 8 Jun 2009 12:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6516) Typo In
 Installation/Getting Started Guide (Version 5 for me)
In-Reply-To: <154239.1234885184491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12414142.1244480396592.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471057#action_12471057 ] 

Paul Nittel commented on JBAS-6516:
-----------------------------------

In the same paragraph, "available" is spelled as "avaialble"

> Typo In Installation/Getting Started Guide (Version 5 for me)
> -------------------------------------------------------------
>
>                 Key: JBAS-6516
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6516
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Docs/Installation and Getting Started Guide
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: All where PDF is viewed.
>            Reporter: Michael McElwee
>            Priority: Trivial
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> On the first sentence under Section 1.4 (Project Structure Changes)...page 11 of 100 of the PDF or page 3 on the printed page, the Installation and Getting Started Guide document has the word 'independent' spelled as 'indepdnent'.  Simple typographical error.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 13:07:56 2009
From: jira-events at lists.jboss.org (Joao Paulo Viragine (JIRA))
Date: Mon, 8 Jun 2009 13:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2408) Add option to
 change layout and theme per page in Dashboard.
Message-ID: <14474841.1244480876536.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add option to change layout and theme per page in Dashboard.
------------------------------------------------------------

                 Key: JBPORTAL-2408
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2408
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
         Environment: EPP 4.3
            Reporter: Joao Paulo Viragine
            Priority: Minor


Nowadays we have only the option to change layout and theme for *entire* dashboard (http://www.redhat.com/docs/en-US/Enterprise_Portal_Platform/4.3/html/User_Guide/Portal_User_Guide-JBoss_Portal_Basics-Dashboard.html)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 13:11:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 8 Jun 2009 13:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-190) Fix
	TreeStructureCache
Message-ID: <5441871.1244481116496.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix TreeStructureCache
----------------------

                 Key: JBDEPLOY-190
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-190
             Project: JBoss Deployers
          Issue Type: Bug
          Components: structure
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA


TreeStructureCache shows strange leaves in MC demos.
e.g. node's names do not equal to node's children; empty names vs. 2 children

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 13:13:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 8 Jun 2009 13:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-190) Fix
	TreeStructureCache
In-Reply-To: <5441871.1244481116496.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22413776.1244481236767.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471059#action_12471059 ] 

Ales Justin commented on JBDEPLOY-190:
--------------------------------------

Currently I have a workaround: also update names if (names.size() != children.size()).
But I still don't see why plain null check is not enough.

> Fix TreeStructureCache
> ----------------------
>
>                 Key: JBDEPLOY-190
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-190
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: structure
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>
> TreeStructureCache shows strange leaves in MC demos.
> e.g. node's names do not equal to node's children; empty names vs. 2 children

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 13:40:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 8 Jun 2009 13:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1642) Make the java
 ee example runnable on windows
Message-ID: <22235800.1244482856551.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make the java ee example runnable on windows
--------------------------------------------

                 Key: JBMESSAGING-1642
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1642
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0 Beta
            Reporter: Jeff Mesnil
            Assignee: Tim Fox
             Fix For: 2.0.0.CR1


The javaee examples are hard-coded for Linux (run.sh is used to start JBoss AS).

For windows users, they have to manually edit the build files to sue run.bat instead.
There is a note in the Beta1 release notes about that.

The windows/linux difference should be parameterized so that the same build file
could be used on both OSes.

The windows file (*.bat) must also be checked to ensure they ends with  \r\n

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 16:11:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 8 Jun 2009 16:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-204) Validation errors
 in jboss_5_1.xsd (missing webservice-descriptionType)
In-Reply-To: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29715657.1244491916686.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471079#action_12471079 ] 

Alexey Loubyansky commented on JBMETA-204:
------------------------------------------

This is what JBoss AS does. All DTDs and XSDs are resolved locally. Implementation of EntityResolver is responsible for that. Here is http://anonsvn.jboss.org/repos/common/common-core/trunk/src/main/java/org/jboss/util/xml/JBossEntityResolver.java as an example.

> Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)
> -----------------------------------------------------------------------
>
>                 Key: JBMETA-204
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Zachary Bedell
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>
> An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 16:43:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 8 Jun 2009 16:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29563401.1244493836959.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6888:
---------------------------------


>From the comments above, it appears we'll need an AOP release to address this issue.  Can you provide an update? 

> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Kabir Khan
>         Attachments: server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun  8 19:07:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 8 Jun 2009 19:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1002) EJB3-based
 version of the RetryInterceptor
In-Reply-To: <7722768.1183386630978.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24051609.1244502476931.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471085#action_12471085 ] 

Brian Stansberry commented on EJBTHREE-1002:
--------------------------------------------

Some notes on this as I've been thinking about it a bit.

Assumption is that the basic EJB2 design of storing the cluster topology in JNDI next to the bean ref, using jndiname + fixed_suffix is followed. (That assumption is open to debate if there are better approaches.)

JndiClusteredSessionRegistrarBase would override superclass bind() method to bind the cluster topology objects in JNDI. Objects would either be a FamilyWrapper, or a Reference with a bunch of StringRefAddr, one per target, and an ObjectFactory to create the FamilyWrapper on the client side.

SessionClusteredProxyObjectFactory.createProxyFactoryProxy would be modified to pass the jndiname to ClusteredPojiProxy via a new property setter. Field for this would be transient to ensure serialization format is unchanged. ClusteredPojiProxy would add this name to the invocation metadata.

The actual retry interceptor would be much like the current one, except than once it has created a FamilyWrapper it doesn't need to bind it to the invocation, since FamilyClusterInfo/ClusteringTargetsRepository ensure there is only one set of targets per family.

> EJB3-based version of the RetryInterceptor
> ------------------------------------------
>
>                 Key: EJBTHREE-1002
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1002
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Paul Ferraro
>
> Looking for a conceptual equivalent to the EJB2 RetryInterceptor -- ability to reestablish a valid remoting client when the current FamilyClusterInfo does not contain any valid targets.
> If the approach is analogous to the RetryInterceptor case, what would be registered in JNDI is the FamilyClusterInfo itself (rather than the EJB2 Invoker). Looking this up in JNDI would provide the current list of targets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 01:10:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 9 Jun 2009 01:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-415) ClientLoginModule
 multi-threaded=false should make SecurityContext
 client side association
Message-ID: <12517767.1244524256604.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClientLoginModule multi-threaded=false should make SecurityContext client side association
------------------------------------------------------------------------------------------

                 Key: SECURITY-415
                 URL: https://jira.jboss.org/jira/browse/SECURITY-415
             Project: JBoss Security and Identity Management
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: 2.0.3.SP1
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: 2.0.3.SP2


The ClientLoginModule multi-threaded=false option when missing, should set SecurityContextAssociation.setClient()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 01:18:33 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 9 Jun 2009 01:18:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-131) WS-Kerberos
In-Reply-To: <10099235.1204727998889.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31476750.1244524713241.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/SECURITY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471107#action_12471107 ] 

Anil Saldhana commented on SECURITY-131:
----------------------------------------

http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150953   has a comment

===================
The ticket needs to be forwardable. If it is, in firefox, you add your website to the trusted URIs for delegation ( in about:config). At this point, you should see "context.getDelegState()=true" in the logs.
The missing bit in the jboss-negotiation project is to get the delegated credendentials and store them in the private credentials of the Subject in the SPNEGOLoginModule. It needs to be destroyed or cleared in the logout method.
Then, you will need to manage yourself the kerberos ticket and implement yourself the WS-kerberos (if your webservice is using a HTTP binding, i suppose it would be easy to secure the webservice via spnego). Jboss does not implement these things for you so, you have to take care of the ticket renewal and propagation...

> WS-Kerberos
> -----------
>
>                 Key: SECURITY-131
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-131
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2.0.4.GA
>
>
> Both incomming and outbound.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 01:41:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 9 Jun 2009 01:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1643) Ordering
 Group incorrect handling on Session close
Message-ID: <2086391.1244526116865.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ordering Group incorrect handling on Session close
--------------------------------------------------

                 Key: JBMESSAGING-1643
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1643
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.4.GA, 1.4.0.SP3.CP08
         Environment: all platform
            Reporter: Howard Gao
            Assignee: Howard Gao
             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA


On session close, all unacknowledged messages will be cancelled. For ordering group messages, if messages are cancelled, it will be redelivered first.
But currently if the message is cancelled, the message is released from the ordering group control, making the second message being delivered. That's broken.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 01:45:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Tue, 9 Jun 2009 01:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-735) Fix the
 2.0.x-compliance-tests.xml script
Message-ID: <8383897.1244526356637.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix the 2.0.x-compliance-tests.xml script
-----------------------------------------

                 Key: JBAOP-735
                 URL: https://jira.jboss.org/jira/browse/JBAOP-735
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.1.GA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: 2.1.2.GA


Currently, if you try to run the precompiled-tests_2.0.x target, this is what you get:

_run-precompiled-test_2.0.x:
     [echo] Compiling bridgemethod with optimized=true and instrumentor ${instrumentor}
     [aopc] Exception in thread "main" java.lang.RuntimeException: Invalid instrumentor ${instrumentor} was used
     [aopc] 	at org.jboss.aop.instrument.InstrumentorFactory.initialise(InstrumentorFactory.java:75)
     [aopc] 	at org.jboss.aop.AspectManager$1.run(AspectManager.java:317)
     [aopc] 	at org.jboss.aop.AspectManager$1.run(AspectManager.java:263)
     [aopc] 	at java.security.AccessController.doPrivileged(Native Method)
     [aopc] 	at org.jboss.aop.AspectManager.initManager(AspectManager.java:262)
     [aopc] 	at org.jboss.aop.AspectManager.instance(AspectManager.java:241)
     [aopc] 	at org.jboss.aop.AspectManager.instance(AspectManager.java:230)
     [aopc] 	at org.jboss.aop.standalone.Compiler.compile(Compiler.java:195)
     [aopc] 	at org.jboss.aop.standalone.Compiler.main(Compiler.java:88)

BUILD FAILED
/qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/build-tests-jdk50.xml:275: The following error occurred while executing this line:
/qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:256: The following error occurred while executing this line:
/qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:486: The following error occurred while executing this line:
/qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:287: The following error occurred while executing this line:
/qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:654: Java returned: 1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 01:47:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Tue, 9 Jun 2009 01:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAOP-735) Fix the
 2.0.x-compliance-tests.xml script
In-Reply-To: <8383897.1244526356637.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19415174.1244526476452.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAOP-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone resolved JBAOP-735.
----------------------------------

    Resolution: Done


> Fix the 2.0.x-compliance-tests.xml script
> -----------------------------------------
>
>                 Key: JBAOP-735
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-735
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>             Fix For: 2.1.2.GA
>
>
> Currently, if you try to run the precompiled-tests_2.0.x target, this is what you get:
> _run-precompiled-test_2.0.x:
>      [echo] Compiling bridgemethod with optimized=true and instrumentor ${instrumentor}
>      [aopc] Exception in thread "main" java.lang.RuntimeException: Invalid instrumentor ${instrumentor} was used
>      [aopc] 	at org.jboss.aop.instrument.InstrumentorFactory.initialise(InstrumentorFactory.java:75)
>      [aopc] 	at org.jboss.aop.AspectManager$1.run(AspectManager.java:317)
>      [aopc] 	at org.jboss.aop.AspectManager$1.run(AspectManager.java:263)
>      [aopc] 	at java.security.AccessController.doPrivileged(Native Method)
>      [aopc] 	at org.jboss.aop.AspectManager.initManager(AspectManager.java:262)
>      [aopc] 	at org.jboss.aop.AspectManager.instance(AspectManager.java:241)
>      [aopc] 	at org.jboss.aop.AspectManager.instance(AspectManager.java:230)
>      [aopc] 	at org.jboss.aop.standalone.Compiler.compile(Compiler.java:195)
>      [aopc] 	at org.jboss.aop.standalone.Compiler.main(Compiler.java:88)
> BUILD FAILED
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/build-tests-jdk50.xml:275: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:256: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:486: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:287: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:654: Java returned: 1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 01:52:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 9 Jun 2009 01:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1643) Ordering
 Group incorrect handling on Consumer close
In-Reply-To: <2086391.1244526116865.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2060249.1244526776523.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1643:
------------------------------------

        Summary: Ordering Group incorrect handling on Consumer close  (was: Ordering Group incorrect handling on Session close)
    Description: 
On session close, all unacknowledged messages will be cancelled. For ordering group messages, if messages are cancelled, it will be redelivered first.
But currently if the message is cancelled, the message is released from the ordering group control, making the second message being delivered. That's broken.

The reason for the wrong order of delivery:

1. msg A is delivered and commited. then B is delivered to client.
2. consumer close() cause B cancelled back to queue. But it is wrongly removed from the linked list.
3. On next deliver, B cannot be delivered because it is not the first in the ordering group (B still an ordering group message). So C is delivered to client.
4. After C is committed, D is delivered to the client and committed.
5. then B is delivered as the whole ordering group is empty now.

  was:
On session close, all unacknowledged messages will be cancelled. For ordering group messages, if messages are cancelled, it will be redelivered first.
But currently if the message is cancelled, the message is released from the ordering group control, making the second message being delivered. That's broken.





> Ordering Group incorrect handling on Consumer close
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1643
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1643
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: all platform
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> On session close, all unacknowledged messages will be cancelled. For ordering group messages, if messages are cancelled, it will be redelivered first.
> But currently if the message is cancelled, the message is released from the ordering group control, making the second message being delivered. That's broken.
> The reason for the wrong order of delivery:
> 1. msg A is delivered and commited. then B is delivered to client.
> 2. consumer close() cause B cancelled back to queue. But it is wrongly removed from the linked list.
> 3. On next deliver, B cannot be delivered because it is not the first in the ordering group (B still an ordering group message). So C is delivered to client.
> 4. After C is committed, D is delivered to the client and committed.
> 5. then B is delivered as the whole ordering group is empty now.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 03:39:56 2009
From: jira-events at lists.jboss.org (Krashan Brahmanjara (JIRA))
Date: Tue, 9 Jun 2009 03:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6122) Regression: Unable
 to deploy self referencing EJB3 session bean
In-Reply-To: <4298875.1224591920917.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24223943.1244533196882.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471117#action_12471117 ] 

Krashan Brahmanjara commented on JBAS-6122:
-------------------------------------------

I can confirm that problem on JBoss 5.1.0GA In my case four ejb bean fails - it works well on Weblogic.

Error log
DEPLOYMENTS MISSING DEPENDENCIES:
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=KBean,service=EJB3" is missing the following dependencies:
    Dependency "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=KBean,service=EJB3>" (should be in state "Described", but is actually in state "** UNRESOLVED Demands 'jndi:testEAR/WBean/local-test.WLocal' **")
    Dependency "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=KBean,service=EJB3>" (should be in state "Described", but is actually in state "** UNRESOLVED Demands 'jndi:testEAR/RBean/local-test.RLocal' **")
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=KBean,service=EJB3_endpoint" is missing the following dependencies:
    Dependency "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=KBean,service=EJB3" (should be in state "Configured", but is actually in state "PreInstall")
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=RBean,service=EJB3" is missing the following dependencies:
    Dependency "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=RBean,service=EJB3>" (should be in state "Described", but is actually in state "** UNRESOLVED Demands 'jndi:testEAR/WBean/local-test.WLocal' **")
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=RBean,service=EJB3_endpoint" is missing the following dependencies:
    Dependency "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=RBean,service=EJB3" (should be in state "Configured", but is actually in state "PreInstall")
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=TBean,service=EJB3" is missing the following dependencies:
    Dependency "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=TBean,service=EJB3>" (should be in state "Described", but is actually in state "** UNRESOLVED Demands 'jndi:testEAR/WBean/local-test.WLocal' **")
    Dependency "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=TBean,service=EJB3>" (should be in state "Described", but is actually in state "** UNRESOLVED Demands 'jndi:testEAR/RBean/local-test.RLocal' **")
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=TBean,service=EJB3_endpoint" is missing the following dependencies:
    Dependency "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=TBean,service=EJB3" (should be in state "Configured", but is actually in state "PreInstall")
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=WBean,service=EJB3" is missing the following dependencies:
    Dependency "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=WBean,service=EJB3>" (should be in state "Described", but is actually in state "** UNRESOLVED Demands 'jndi:testEAR/RBean/local-test.RLocal' **")
  Deployment "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=WBean,service=EJB3_endpoint" is missing the following dependencies:
    Dependency "jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=WBean,service=EJB3" (should be in state "Configured", but is actually in state "PreInstall")

DEPLOYMENTS IN ERROR:
  Deployment "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=WBean,service=EJB3>" is in error due to the following reason(s): ** UNRESOLVED Demands 'jndi:testEAR/RBean/local-test.RLocal' **
  Deployment "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=KBean,service=EJB3>" is in error due to the following reason(s): ** UNRESOLVED Demands 'jndi:testEAR/WBean/local-test.WLocal' **, ** UNRESOLVED Demands 'jndi:testEAR/RBean/local-test.RLocal' **
  Deployment "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=TBean,service=EJB3>" is in error due to the following reason(s): ** UNRESOLVED Demands 'jndi:testEAR/WBean/local-test.WLocal' **, ** UNRESOLVED Demands 'jndi:testEAR/RBean/local-test.RLocal' **
  Deployment "<UNKNOWN jboss.j2ee:ear=demo.ear,jar=ejb.jar,name=RBean,service=EJB3>" is in error due to the following reason(s): ** UNRESOLVED Demands 'jndi:testEAR/WBean/local-test.WLocal' **

> Regression: Unable to deploy self referencing EJB3 session bean
> ---------------------------------------------------------------
>
>                 Key: JBAS-6122
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6122
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: Fedora Linux 9, Sun JDK 1.6.0_06
>            Reporter: Radu Radutiu
>            Assignee: Carlo de Wolf
>
> The following stateless EJB which has a self reference using @EJBs() annotation deploys fine on jboss-4.2.3 but fails to deploy on jboss-5.0.0CR2. 
> package test;
> import javax.ejb.*;
> @EJBs({@EJB(name="TestSessionBean/local",beanInterface=LocalTestSession.class,beanName="TestSessionBean")})
> @Stateless(name="TestSessionBean")
> public class TestSessionBean implements LocalTestSession {
> 	public String test() {
> 		try {
> 	        InitialContext ic = new InitialContext();
> 	        LocalTestSession lc = (LocalTestSession) ic.lookup("java:comp/env/TestSessionBean/local");
> 	        System.out.println(lc.test1());
>         } catch (NamingException e) {
> 	        e.printStackTrace();
>         }
> 		return "test";
> 	}
> 	
> 	public String test1() {
> 		return "test1";
> 	}
> 	
> }
> When deploying the jar on jboss-5.0.0CR2 I get the following error:
> 09:57:19,227 WARN  [HDScanner] Failed to process changes
> org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE
>  PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> jboss.j2ee:ear=test.jar,jar=test.jar,name=TestSessionBean,service=EJB3
>  -> <UNKNOWN jboss.j2ee:ear=test.jar,jar=test.jar,name=TestSessionBean,service=EJB3>{Described:** UNRESOLVED Demands 'jndi:TestSessionBean/local-test.LocalTestSession' **}
> *** CONTEXTS IN ERROR: Name -> Error
> <UNKNOWN jboss.j2ee:ear=test.jar,jar=test.jar,name=TestSessionBean,service=EJB3> -> ** UNRESOLVED Demands 'jndi:TestSessionBean/local-test.LocalTestSession' **

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 04:51:57 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Tue, 9 Jun 2009 04:51:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-83)
 NullPointerException in Handler#getType
In-Reply-To: <2275005.1244109956457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5075943.1244537517658.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-83.
----------------------------------

    Fix Version/s: 3.11.0.GA
       Resolution: Done


> NullPointerException in Handler#getType
> ---------------------------------------
>
>                 Key: JASSIST-83
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-83
>             Project: Javassist
>          Issue Type: Bug
>         Environment: JA version 3.4, Windows Vista and JDK 1.6.0_10
>            Reporter: Hans-Joerg Adel
>            Assignee: Shigeru Chiba
>            Priority: Optional
>             Fix For: 3.11.0.GA
>
>         Attachments: Sample.java, SampleClass.java
>
>
> Hi!
> When I use ExprEditor#edit(Handler) to access a try-statement without a catch-clause I get a NullPointerException. 
> To reproduce the bug, please use this source
> /*--- (C) 1999-2008 Techniker Krankenkasse ---*/
> package samplepackage;
> import javassist.CannotCompileException;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.NotFoundException;
> import javassist.expr.ExprEditor;
> import javassist.expr.Handler;
> public class Sample {
> 	public static void main(String[] args) throws NotFoundException, CannotCompileException {
> 		ClassPool classPool = ClassPool.getDefault();
> 		CtClass ctClass = classPool.get("samplepackage.SampleClass");
> 		ctClass.instrument(new MyExprEditor());
> 	}
> 	static class MyExprEditor extends ExprEditor {
> 		@Override
> 		public void edit(Handler h) throws CannotCompileException {
> 			try {
> 				h.getType();
> 			} catch (NotFoundException e) {
> 			}
> 		}
> 	}
> }
> Stacktrace:
> Exception in thread "main" java.lang.NullPointerException
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:517)
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:499)
> 	at javassist.expr.Handler.getType(Handler.java:76)
> 	at samplepackage.Sample$MyExprEditor.edit(Sample.java:25)
> 	at javassist.expr.ExprEditor.doit(ExprEditor.java:97)
> 	at javassist.CtClassType.instrument(CtClassType.java:1224)
> 	at samplepackage.Sample.main(Sample.java:17)
> I would expect that h.getType() returns null.
> I am using JA version 3.4, Windows Vista and JDK 1.6.0_10.
> Cheers
> Ruwen
> iA Hans-Joerg Adel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 06:11:56 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Tue, 9 Jun 2009 06:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JASSIST-79) Editing
 MethodCall produces
 incorrect byte code | java.lang.VerifyError: Illegal target of jump or
 branch | goto points to invalid instruction
In-Reply-To: <25834444.1239876805355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32087675.1244542316497.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JASSIST-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471145#action_12471145 ] 

Shigeru Chiba commented on JASSIST-79:
--------------------------------------

Thank you for posting jinsi-jassist-79.tgz.  I got why the generated class file was broken.

The bytecode GOTO takes only 16bit offset.  Since your instrumented method was bigger than 64K, Javassist could not calculate a valid offset.  To fix this problem, GOTO must be replaced with GOTO_W.  Modifying Javassist to do so is not a simple task, give me some time.

> Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | goto points to invalid instruction
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-79
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-79
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>         Environment: $ java -version
> java version "1.6.0_07"
> Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
> Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)
>            Reporter: Martin Burger
>            Assignee: Shigeru Chiba
>         Attachments: jinsi-jassist-79.tgz, Parser.instrumented.class, Parser.instrumented.dump, Parser.original.class, Parser.original.dump, Parser.original.jad, Parser.original.java
>
>
> I instrument method calls in a class called org.mozilla.javascript.Parser.
> If I run (or, load) this class, a java.lang.VerifyError will be thrown:
> Exception in thread "main" java.lang.VerifyError: (class: org/mozilla/javascript/Parser, method: statementHelper signature: (Lorg/mozilla/javascript/TokenStream;)Ljava/lang/Object;) Illegal target of jump or branch
> It seems Javassist introduces a defective goto statement at position 3200 in method statementHelper:
> 3200:        goto    -29495
> Obviously, offset -29495 is an invalid opcode address.
> The corresponding Java code (excerpt):
>         switch(tt) {
>         case TokenStream.IF: {
>             skipsemi = true;
>             sourceAdd((char)ts.IF);
>             int lineno = ts.getLineno();
>             Object cond = condition(ts);
>             sourceAdd((char)ts.LC);
>             sourceAdd((char)ts.EOL);
>             Object ifTrue = statement(ts);
>             Object ifFalse = null;
>             if (ts.matchToken(ts.ELSE)) {
>                 sourceAdd((char)ts.RC);
>                 sourceAdd((char)ts.ELSE);
>                 sourceAdd((char)ts.LC);
>                 sourceAdd((char)ts.EOL);
>                 ifFalse = statement(ts);
>             }
>             sourceAdd((char)ts.RC);
>             sourceAdd((char)ts.EOL);
>             pn = nf.createIf(cond, ifTrue, ifFalse, lineno);
>             break;
>         }
>         case TokenStream.SWITCH: {
> I think the break statement is related to this defect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 06:46:57 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Tue, 9 Jun 2009 06:46:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JASSIST-67) Strange
 Exception: Register x contains wrong type
In-Reply-To: <30186178.1225447340883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27199141.1244544417016.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JASSIST-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471149#action_12471149 ] 

Shigeru Chiba commented on JASSIST-67:
--------------------------------------

This bug is that Javassist wrongly produced IINC instruction for incrementing a local variable at an index more than 8bit.  I will fix it.

> Strange Exception: Register x contains wrong type
> -------------------------------------------------
>
>                 Key: JASSIST-67
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-67
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.8.1.GA
>         Environment: windowsXP
>            Reporter: kobe valiant
>            Assignee: Shigeru Chiba
>            Priority: Blocker
>
>         ClassPool pool = new ClassPool(true);
>         CtClass ctc = pool.makeClass("my.Clazz");
>         StringBuilder sb = new StringBuilder("public void test() {");
>         for (int i = 0; i < 1000; i++) {
>         sb.append("for(int i=0; i<10; i++) {}");                  // line 1
> //      sb.append("for(int i=0; i<10; i++) {int j=i;}");        // line 2
>         }
>         sb.append("}");
>         ctc.addMethod(CtNewMethod.make(sb.toString(), ctc));
>         ctc.toClass().newInstance();
> 	
> the code above will throw an exception:
> Exception in thread "main" java.lang.VerifyError: (class: my/Clazz, method: test signature: ()V) Register 0 contains wrong type
> But if you comment the line 1 and uncomment the line 2, there will no exception at all.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 06:59:56 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Tue, 9 Jun 2009 06:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-67) Strange Exception:
 Register x contains wrong type
In-Reply-To: <30186178.1225447340883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4282632.1244545196649.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-67.
----------------------------------

    Fix Version/s: 3.11.0.GA
       Resolution: Done


> Strange Exception: Register x contains wrong type
> -------------------------------------------------
>
>                 Key: JASSIST-67
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-67
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.8.1.GA
>         Environment: windowsXP
>            Reporter: kobe valiant
>            Assignee: Shigeru Chiba
>            Priority: Blocker
>             Fix For: 3.11.0.GA
>
>
>         ClassPool pool = new ClassPool(true);
>         CtClass ctc = pool.makeClass("my.Clazz");
>         StringBuilder sb = new StringBuilder("public void test() {");
>         for (int i = 0; i < 1000; i++) {
>         sb.append("for(int i=0; i<10; i++) {}");                  // line 1
> //      sb.append("for(int i=0; i<10; i++) {int j=i;}");        // line 2
>         }
>         sb.append("}");
>         ctc.addMethod(CtNewMethod.make(sb.toString(), ctc));
>         ctc.toClass().newInstance();
> 	
> the code above will throw an exception:
> Exception in thread "main" java.lang.VerifyError: (class: my/Clazz, method: test signature: ()V) Register 0 contains wrong type
> But if you comment the line 1 and uncomment the line 2, there will no exception at all.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 07:10:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 9 Jun 2009 07:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7004) EJB3Deployer does
 not use the
 correct MC API and ends up picking irrelevant deployments
Message-ID: <19181380.1244545856566.JavaMail.jira@cloud.prod.atl2.jboss.com>

EJB3Deployer does not use the correct MC API and ends up picking irrelevant deployments
---------------------------------------------------------------------------------------

                 Key: JBAS-7004
                 URL: https://jira.jboss.org/jira/browse/JBAS-7004
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: jaikiran pai
            Assignee: jaikiran pai


EJB3Deployer currently uses the addInput(MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME); API of MC deployers and expects that it will be invoked only if the MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME attachment is available in the deployment unit. However, this is not the right API to use. This results in the EJB3Deployer being invoked for irrelevant deployments as shown here http://lists.jboss.org/pipermail/jboss-development/2009-June/014560.html

The MC forum thread explaining the API usage is here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156725

  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 07:14:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 9 Jun 2009 07:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1634) Remove
	easymock
In-Reply-To: <5508204.1243428380565.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8164124.1244546096494.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1634:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Remove easymock
> ---------------
>
>                 Key: JBMESSAGING-1634
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1634
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0.CR1
>
>
> There are still a load of tests using easymock.
> Including timing tests, unit tests etc.
> These should be ported so we can remove easymock

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:07:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Tue, 9 Jun 2009 08:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2409) Unable to delete
 property without value in portal admin interface
Message-ID: <15281741.1244549276551.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unable to delete property without value in portal admin interface
-----------------------------------------------------------------

                 Key: JBPORTAL-2409
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2409
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Web
    Affects Versions: 2.7.3 Final
            Reporter: Viliam Rockai
            Assignee: Chris Laprun


This bug is present in at least three places:
-Manage properties for all portals
-Properties of each portal
-Dashboards  

in these interfaces it is possible to add values with custom names. when the property is added, it's default value is blank. when a property with blank value is to be deleted (clicking on the delete icon next to the property) nothing will happen. if some value is added to the property, it can be deleted. If you delete the value of some existing property, it can't be deleted.

after clicking on delete button (page is reloaded) for property without a value, you cannot even delete properties with values until you set values to the blank fields.

excerpt from the log:
14:07:45,694 ERROR [STDERR] Jun 9, 2009 2:07:45 PM javax.faces.component.UIInput updateModel
SEVERE: /jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean
java.lang.NullPointerException
	at org.jboss.portal.faces.gui.ManagedBean.getLocalizedType(ManagedBean.java:131)
	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:85)
	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:75)
	at org.jboss.portal.core.admin.ui.PropertyBean.setValue(PropertyBean.java:108)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
.........
14:07:45,918 INFO  [lifecycle] WARNING: FacesMessage(s) have been enqueued, but may not have been displayed.
sourceId=_AdminPortletWindow:j_id132:common-manage-prop-form:prop-data-table:0:prop-value-input[severity=(ERROR 2), summary=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean), detail=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean)]



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:19:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 9 Jun 2009 08:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1643) Ordering Group
 incorrect handling on Consumer close
In-Reply-To: <2086391.1244526116865.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26671400.1244549996648.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1643.
-----------------------------------

    Resolution: Done


> Ordering Group incorrect handling on Consumer close
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1643
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1643
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: all platform
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> On session close, all unacknowledged messages will be cancelled. For ordering group messages, if messages are cancelled, it will be redelivered first.
> But currently if the message is cancelled, the message is released from the ordering group control, making the second message being delivered. That's broken.
> The reason for the wrong order of delivery:
> 1. msg A is delivered and commited. then B is delivered to client.
> 2. consumer close() cause B cancelled back to queue. But it is wrongly removed from the linked list.
> 3. On next deliver, B cannot be delivered because it is not the first in the ordering group (B still an ordering group message). So C is delivered to client.
> 4. After C is committed, D is delivered to the client and committed.
> 5. then B is delivered as the whole ordering group is empty now.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:25:03 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1504) Full Journal
	Compactation
In-Reply-To: <33137475.1234453664451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4596929.1244550323889.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1504:
---------------------------------

    Priority: Critical  (was: Major)


> Full Journal Compactation
> -------------------------
>
>                 Key: JBMESSAGING-1504
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1504
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:31:22 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:31:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1636) AS 5 Admin
 Console integration
In-Reply-To: <6038052.1243518836528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1546518.1244550682745.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1636:
---------------------------------

    Fix Version/s: 2.1.0.beta
                       (was: 2.0.0.CR1)


> AS 5 Admin Console integration
> ------------------------------
>
>                 Key: JBMESSAGING-1636
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1636
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.1.0.beta
>
>
> AS 5 admin console manages JBM 1.4 by default.
> When JBoss Messaging 2 is used, we need to make sure that the admin console allows
> to manage JMS resources (through JMX or by providing a JON plug-in?)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:31:23 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1634) Remove easymock
In-Reply-To: <5508204.1243428380565.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8065421.1244550683236.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-1634.
--------------------------------

    Resolution: Done


> Remove easymock
> ---------------
>
>                 Key: JBMESSAGING-1634
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1634
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0.CR1
>
>
> There are still a load of tests using easymock.
> Including timing tests, unit tests etc.
> These should be ported so we can remove easymock

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:31:23 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-340) Static selector
	queues
Message-ID: <31649357.1244550683946.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-340.
-------------------------------

    Resolution: Out of Date


> Static selector queues
> ----------------------
>
>                 Key: JBMESSAGING-340
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-340
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0.CR1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> We should consider adding functionality to allow a selector to be associated with a queue in the deployment descriptor. The queue then does not accept any messages that do not match the selector. This is in addition to the standard jms functionality of specifying selectors on message consumers.
> It should give better performance in those cases where it is possible to know a selector to apply to an entire queue in advance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:31:21 2009
From: jira-events at lists.jboss.org (Dominik Pospisil (JIRA))
Date: Tue, 9 Jun 2009 08:31:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-984) JGroups can not
 parse IPV6 literals in TCPPING protocol configuration
In-Reply-To: <7188979.1242741125294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24940359.1244550681665.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471166#action_12471166 ] 

Dominik Pospisil commented on JGRP-984:
---------------------------------------

yes, "::1[7810]" works but e. g.: 
 
 "3ffe:ffff:100:f101::3[7810],3ffe:ffff:100:f101::2[7810]" 
 
 does not: 
 14:21:15,754 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "3ffe:ffff:100:f101::3" 
 14:21:15,754 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "3ffe:ffff:100:f101::2"

> JGroups can not parse IPV6 literals in TCPPING protocol configuration
> ---------------------------------------------------------------------
>
>                 Key: JGRP-984
>                 URL: https://jira.jboss.org/jira/browse/JGRP-984
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.6
>            Reporter: Brian Stansberry
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> ON JBPAPP-2013 Dominik Pospisil reports the IPv6 address parsing fix in 2.4.6 doesn't handle TCPPING:
> Both
> <TCPPING initial_hosts="::1[7810],fec0::f101:21a:a0ff:fea0:d745[7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> and
> <TCPPING initial_hosts="[::1][7810],[fec0::f101:21a:a0ff:fea0:d745][7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> fails with:
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "::1"
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "fec0::f101:21a:a0ff:fea0:d745"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:31:21 2009
From: jira-events at lists.jboss.org (Dominik Pospisil (JIRA))
Date: Tue, 9 Jun 2009 08:31:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JGRP-984) JGroups can not
 parse IPV6 literals in TCPPING protocol configuration
In-Reply-To: <7188979.1242741125294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27467667.1244550682016.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dominik Pospisil reopened JGRP-984:
-----------------------------------



> JGroups can not parse IPV6 literals in TCPPING protocol configuration
> ---------------------------------------------------------------------
>
>                 Key: JGRP-984
>                 URL: https://jira.jboss.org/jira/browse/JGRP-984
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.6
>            Reporter: Brian Stansberry
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> ON JBPAPP-2013 Dominik Pospisil reports the IPv6 address parsing fix in 2.4.6 doesn't handle TCPPING:
> Both
> <TCPPING initial_hosts="::1[7810],fec0::f101:21a:a0ff:fea0:d745[7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> and
> <TCPPING initial_hosts="[::1][7810],[fec0::f101:21a:a0ff:fea0:d745][7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> fails with:
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "::1"
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "fec0::f101:21a:a0ff:fea0:d745"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:31:22 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:31:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1427) Journal
	Cleanup
In-Reply-To: <6551971.1222785211162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8039177.1244550682231.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1427:
---------------------------------

    Priority: Critical  (was: Major)


> Journal Cleanup
> ---------------
>
>                 Key: JBMESSAGING-1427
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1427
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> If a destination is lazy, not consuming messages for a long time, the journal will grow until those messages are consumed.
> This would be a problem with DLQs or messages taking days before they are consumed.
> Since we inform the TransactionSummary on commits, we could change the journal to support multiple current-files based on configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:31:24 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:31:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1640)
 ClientSessionFactory are
 garbage collected while the sessions are used in the integration tests
In-Reply-To: <21551780.1244203796542.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31253449.1244550684251.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-1640.
--------------------------------

    Resolution: Out of Date


> ClientSessionFactory are garbage collected while the sessions are used in the integration tests
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1640
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1640
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0.CR1
>
>
> The client session impl does not have a ref on the factory which was used to create it.
> In the integration-tests (e.g. ClientConsumerCloseTest),  there are a lot of:
> protected void setUp() throws Exception
> {
>    ClientSessionFactory sf = new ClientSessionFactoryImpl(new TransportConfiguration(InVMConnectorFactory.class.getName()));
>    ... 
>    session = sf.createSession(false, true, true);
>    session.createQueue(address, queue, false);
> }
> In that case, the sf variable will be GC'ed while the session field is still used which could lead to problems.
> The factory *must not* be GC'ed while it still has sessions. To prevent that in all case, we can add a reference to the factory
> in the created sessions.
> For the integration-tests, we must also ensure that the sf is properly closed by making the sf a field and call close() in the
> teardown methods.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:32:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1433) Enable
 replication for browsers
In-Reply-To: <3332141.1224406292113.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33016943.1244550776537.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1433:
---------------------------------

    Priority: Critical  (was: Major)


> Enable replication for browsers
> -------------------------------
>
>                 Key: JBMESSAGING-1433
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1433
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> Making a copy of the queue for a browser consumer doesn't work well with replication since
> When replicating the create consumer (browser) to the backup, when executed on the backup the
> backup may have different messages in its queue since been added on different threads.
> So when replicating deliveries they may not be found.
> Uncomment MultiThreadRandomFailoverTest::testM when this is complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:32:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1583) Fix message
 redistribution with replication
In-Reply-To: <28198275.1239022282568.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23620935.1244550776968.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1583:
---------------------------------

    Priority: Critical  (was: Major)


> Fix message redistribution with replication
> -------------------------------------------
>
>                 Key: JBMESSAGING-1583
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1583
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> Message redistribution in a replicated cluster is currently broken. Needs to be fixed and thoroughly tested.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:34:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1424) Provider
 strict message ordering via "ordering groups"
In-Reply-To: <25015723.1222415841133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32442056.1244550896706.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1424:
---------------------------------

    Priority: Critical  (was: Major)


> Provider strict message ordering via "ordering groups"
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1424
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1424
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> See linked task

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:34:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1602) Remove code
 duplication for queue creation
In-Reply-To: <9137314.1239981322726.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6103448.1244550896933.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-1602.
--------------------------------

    Resolution: Out of Date


> Remove code duplication for queue creation
> ------------------------------------------
>
>                 Key: JBMESSAGING-1602
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1602
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0.CR1
>
>
> there should be only 1 place to create a (core) queue in JBM: MessagingServer.createQueue()
> but this code is duplicated in:
> MessagingServerImpl.doStart()
> MessagingServerImpl.deployQueues()
> MessagingServerControl.createQueue() (2 methods)
> ServerSessionImpl.doHandleCreateConsumer (temp code for queue browsing)
> All this duplicated code should be removed by making sure that MessagingServer.createQueue() handles everything.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:36:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1325) Sync a backup
 server with a live server
In-Reply-To: <2662823.1211906159940.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23346072.1244551016450.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1325:
---------------------------------

    Priority: Critical  (was: Major)


> Sync a backup server with a live server
> ---------------------------------------
>
>                 Key: JBMESSAGING-1325
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1325
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> If a live server has no backup server, should be able to bring one up while the live is running and for them to auto-sync.
> This is useful if the server has failed over to its backup, and you won't to bring up another backup for the failed over server.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:38:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-342) Functional
 tests bundled with the release should be functional
Message-ID: <25146716.1244551136747.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-342.
-------------------------------

    Resolution: Rejected


> Functional tests bundled with the release should be functional
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-342
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-342
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 2.0.0.CR1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> The functional tests whose source code comes with the release should be compilable and runnable, so they can validate the release at unpacking.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:45:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1176) The Bridge
 Mbean needs refactoring
In-Reply-To: <9744544.1196863552263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16384202.1244551556985.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-1176.
--------------------------------

    Resolution: Out of Date


> The Bridge Mbean needs refactoring
> ----------------------------------
>
>                 Key: JBMESSAGING-1176
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1176
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Andy Taylor
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0.CR1
>
>
> The bridge mbean also needs refactoring to be a pojo. Also we need to decide how, and if, this would work in an embedded deployment

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:49:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1400) Allow users
 to configure a system wide maximum connection limit
In-Reply-To: <8050340.1216224002198.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28706527.1244551797408.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1400:
---------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.GA)


> Allow users to configure a system wide maximum connection limit
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1400
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1400
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Jay Howell
>            Assignee: Tim Fox
>             Fix For: 2.0.0.CR1
>
>
> Many users are complaining of errors that say "Too many open files", which comes from the number of sockets open during jms processing. It's currently possible to run the system out of resources.  We currently only have control of this through the remoting/netty/mina layer.  We should have a setting in JBM that limits the number of connections systemwide, that is independent of the remoting protocol/package.  This way users wouldn't have to keep learning a new package/configuration setting each time the communications package changes in jbm.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:49:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1399) Allow users
 to configure a system wide maximum session limit
In-Reply-To: <4175115.1216223127220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28217025.1244551796957.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1399:
---------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.GA)


> Allow users to configure a system wide maximum session limit
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1399
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1399
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jay Howell
>            Assignee: Tim Fox
>             Fix For: 2.0.0.CR1
>
>
> Goal: keep external/internal clients from running the system out of resources(threads/memory).
> We currently have a problem where there is no limit to the number of sessions that can be created in the system.  It would be theoretically possible to have an external client create 1 million sessions in one connection and run the sever out of resources.   It's also possible to set the number of max sessions for an mdb high enough to run the system out of resources(threads/memory).  We need to be able to set a limit for the number of sessions for the system. 
> I've looked at other Messaging systems, like IBM MQ and it seems that other systems have the same setting. 
> We've had users naively suggest that we could implement this by using a bounded thread pool.  This seems too intrusive and too dangerous to do.  This can be done by limiting the number of sessions in the system, which seems like a much better suggestion.  This is much better than using a bounded thread pool for many reasons.  A couple of the reasons is..
> 1.  It doesn't expose the internal workings of JBM to the management console(leaky abstraction).  
> 2.  Users can understand a session limit easier than having to understand the internal thread pool implementation.
> 3.  Doesn't incur deadlocks
> 4.  Allows All clients to get back a message that says some thing like "Session limit reached".
> JBM 2.0 uses an unbounded thread pool for threads, which addresses any concern any performance difficulties with creating and destroying threads.  So now we can address the max number of threads in the system by configuring max sessions in the system.
> Setting a session limit seems to be a more reasonable approach than the bounded thread pool

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:49:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1432)
 ReceiveImmediate on consumer should check the server for messages
In-Reply-To: <2499468.1224263600985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19022517.1244551797181.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1432:
---------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.GA)


> ReceiveImmediate on consumer should check the server for messages
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1432
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1432
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Andy Taylor
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0.CR1
>
>
> When receiveImmediate() is called on a client consumer it only checks its internal buffer. It should also check with the server to make sure there are no messages in transit or waiting to be delivered. Once this is done the Queue Browser can be changed to use this instead of a timeout receive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 08:49:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 9 Jun 2009 08:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1604) Hot deployment
 of JMS resource does not work in a replicated environment
In-Reply-To: <21890091.1240492573820.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11342995.1244551796726.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-1604.
--------------------------------

    Resolution: Out of Date


> Hot deployment of JMS resource does not work in a replicated environment
> ------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1604
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1604
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0.CR1
>
>
> JBoss Messaging allow hot deployment of JMS resources (connection factories & destinations) by adding corresponding entries in jbm-jms.xml configuration file.
> However, resources deployed from this file are only deployed locally and are not replicated on the backup node (if there is one).
> The deployment code must be updated so that resources deployed by the JMSServerDeployer use a replication-aware management controls to create the resources rather than doing it directly using JMSServerManager.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 09:33:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 9 Jun 2009 09:33:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7004) EJB3Deployer does
 not use the
 correct MC API and ends up picking irrelevant deployments
In-Reply-To: <19181380.1244545856566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11286327.1244554437262.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471190#action_12471190 ] 

jaikiran pai commented on JBAS-7004:
------------------------------------

The org.jboss.ejb3.deployers.Ejb3Deployer has been changed to use the correct MC API for setting JBossMetadata as a requirement.

> EJB3Deployer does not use the correct MC API and ends up picking irrelevant deployments
> ---------------------------------------------------------------------------------------
>
>                 Key: JBAS-7004
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7004
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> EJB3Deployer currently uses the addInput(MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME); API of MC deployers and expects that it will be invoked only if the MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME attachment is available in the deployment unit. However, this is not the right API to use. This results in the EJB3Deployer being invoked for irrelevant deployments as shown here http://lists.jboss.org/pipermail/jboss-development/2009-June/014560.html
> The MC forum thread explaining the API usage is here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156725
>   

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 09:33:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 9 Jun 2009 09:33:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7004) EJB3Deployer does
 not use the
 correct MC API and ends up picking irrelevant deployments
In-Reply-To: <19181380.1244545856566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25564762.1244554437135.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-7004.
--------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


> EJB3Deployer does not use the correct MC API and ends up picking irrelevant deployments
> ---------------------------------------------------------------------------------------
>
>                 Key: JBAS-7004
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7004
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> EJB3Deployer currently uses the addInput(MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME); API of MC deployers and expects that it will be invoked only if the MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME attachment is available in the deployment unit. However, this is not the right API to use. This results in the EJB3Deployer being invoked for irrelevant deployments as shown here http://lists.jboss.org/pipermail/jboss-development/2009-June/014560.html
> The MC forum thread explaining the API usage is here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156725
>   

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 09:35:57 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 9 Jun 2009 09:35:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7005) Logging categories
Message-ID: <4751763.1244554557239.JavaMail.jira@cloud.prod.atl2.jboss.com>

Logging categories
------------------

                 Key: JBAS-7005
                 URL: https://jira.jboss.org/jira/browse/JBAS-7005
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Logging
            Reporter: Jesper Pedersen
            Assignee: Scott Marlow
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


The jboss-log4j.xml should contain categories to limit the logging of all classes used during startup.

An example what is missing currently is

   <!-- Limit Arjuna
   <category name="com.arjuna">
      <priority value="INFO"/>
   </category>
   -->


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 09:37:57 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 9 Jun 2009 09:37:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7005) Logging categories
In-Reply-To: <4751763.1244554557239.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12168127.1244554677257.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow reassigned JBAS-7005:
----------------------------------

    Assignee: Scott Marlow  (was: Scott Marlow)


> Logging categories
> ------------------
>
>                 Key: JBAS-7005
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7005
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Jesper Pedersen
>            Assignee: Scott Marlow
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The jboss-log4j.xml should contain categories to limit the logging of all classes used during startup.
> An example what is missing currently is
>    <!-- Limit Arjuna
>    <category name="com.arjuna">
>       <priority value="INFO"/>
>    </category>
>    -->

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 10:46:57 2009
From: jira-events at lists.jboss.org (Zachary Bedell (JIRA))
Date: Tue, 9 Jun 2009 10:46:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-204) Validation errors
 in jboss_5_1.xsd (missing webservice-descriptionType)
In-Reply-To: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31750062.1244558817138.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471225#action_12471225 ] 

Zachary Bedell commented on JBMETA-204:
---------------------------------------

Hmm... So then it's likely that any attempts I'm making to customize the retrieval locations via setting schemaLocation aren't actually having an effect?

At this point, I wonder if the 5.1 schemas are something that "should" be used?  I've not been able to get JBoss 5.1.0.GA to deploy an app which was working under 4.2.3.  Falling back to the 5.0 schemas (with the XML prolog in jboss.xml below) does appear to pass validation.

<jboss xmlns="http://www.jboss.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss_5_0.xsd"
       version="3.0">

The jboss.xml *does* validate when checked in an XML editor on my development machine, both with the 5_0 and 5_1 versions of the schema in the prolog (and the file otherwise unmodified).  Trying with the 5_1 fails at deployment with "xml is not well formed".  Starting up with trace level logging lists messages like the following for all of the elements in jboss.xml before it finally fails:

[RtElementHandler] startElement {http://www.jboss.com/xml/ns/javaee}jboss parent=null term=org.jboss.xb.binding.sunday.unmarshalling.ElementBinding at 2ddde6d0({http://www.jboss.com/xml/ns/javaee}jboss, type={http://www.jboss.com/xml/ns/javaee}jbossType)
[RtElementHandler] Failed to resolve class for element {http://www.jboss.com/xml/ns/javaee}jboss: com.jboss.xml.ns.javaee.JbossType

Deploying with the 5_0 schemas appears okay (I'm running into other problems further along now).  If the 5_1 schemas aren't considered "production ready" at this point, then this ticket can probably close out as is.  If they *are* supposed to be ready, then there's still an issue.  I can definitely provided additional logs and samples of the XML if that's the case.


> Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)
> -----------------------------------------------------------------------
>
>                 Key: JBMETA-204
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Zachary Bedell
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>
> An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 11:58:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 9 Jun 2009 11:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1644) Work out a
 suitable way to provide JBM examples/doc for AS 5
Message-ID: <25933843.1244563136418.JavaMail.jira@cloud.prod.atl2.jboss.com>

Work out a suitable way to provide JBM examples/doc for AS 5
------------------------------------------------------------

                 Key: JBMESSAGING-1644
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1644
             Project: JBoss Messaging
          Issue Type: Task
          Components: AS Integration
    Affects Versions: 1.4.3.GA
            Reporter: Howard Gao
            Assignee: Howard Gao
            Priority: Critical
             Fix For: 1.4.5.GA


Current AS 5 distribution kit doesn't have JBM doc/examples of the corresponding version included, that makes it very inconvenient to use JBM with AS5. Users often get confused with which version of JBM is the correct version, and where to get the resouces (docs, examples).

We have to provide a solution to that. 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 12:31:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 9 Jun 2009 12:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7006) Error starting JMS
 Destination service via AS admin console
Message-ID: <19122080.1244565116599.JavaMail.jira@cloud.prod.atl2.jboss.com>

Error starting JMS Destination service via AS admin console
-----------------------------------------------------------

                 Key: JBAS-7006
                 URL: https://jira.jboss.org/jira/browse/JBAS-7006
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMX/Web Console
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Howard Gao
            Assignee: Darran Lofthouse


To reproduce:

1. deploy a queue service in AS_home/server/all/deploy/messaging/destinations-service.xml
2. start AS : run.sh -c all
3. log in to JBoss AS Administration Console, click 'JMS Destinations' then 'Queues'. 
4. Then click the queue on the right pane. Client the 'Control' tab.
5. first click 'stop' operation, it will result in success. Then click 'start', it will fail with the following log message:

java.lang.reflect.UndeclaredThrowableException: Failed to invoke method 'start' on component 'jboss.messaging.destination:name=123456789012345,service=Queue' with parameters [].
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.invoke(KernelBusRuntimeComponentDispatcher.java:201)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:69)
        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.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java)
        at org.jboss.profileservice.management.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:64)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.invokeOperation(ManagedComponentComponent.java:159)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:482)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalArgumentException: No such context: jboss.messaging.destination:name=123456789012345,service=Queue
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:51)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.invoke(BasicKernelBus.java:92)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.invoke(KernelBusRuntimeComponentDispatcher.java:186)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:69)
        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.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java)
        at org.jboss.profileservice.management.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:64)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.invokeOperation(ManagedComponentComponent.java:159)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:482)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 18 more


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 12:31:56 2009
From: jira-events at lists.jboss.org (Robert Wolinski (JIRA))
Date: Tue, 9 Jun 2009 12:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-5199) Exception in
 server.log during startup
In-Reply-To: <17236534.1201884010347.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7389606.1244565116845.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471259#action_12471259 ] 

Robert Wolinski commented on JBAS-5199:
---------------------------------------

I have the same problem in 5.0.1. I'm trying to debug some webservice problems and this popping up in the exception stack makes troubleshooting all that more difficult.

> Exception in server.log during startup
> --------------------------------------
>
>                 Key: JBAS-5199
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5199
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  JBossAS-5.0.0.Beta3
>         Environment: windows xp; jboss 5.0.0Beta3
>            Reporter: Scott Dickerson
>         Attachments: boot.log, server.log
>
>
> 2008-02-01 11:28:19,685 DEBUG [org.jboss.mx.loading.UnifiedLoaderRepository3] Failed to update pkgs for cl=org.jboss.mx.loading.UnifiedClassLoader3 at 473fc2{ url=vfsfile:/C:/JavaTools/jboss-5.0.0.Beta3/server/test/deploy/http-invoker.sar/ ,addedOrder=20}
> java.io.FileNotFoundException: C:\JavaTools\jboss-5.0.0.Beta3\server\test\deploy\http-invoker.sar\invoker.war\WEB-INF\classes (Access is denied)
> 	at java.io.FileInputStream.open(Native Method)
> 	at java.io.FileInputStream.<init>(FileInputStream.java:106)
> 	at org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:105)
> 	at java.net.URL.openStream(URL.java:1007)
>         ....
> (see attached server.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 12:58:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 9 Jun 2009 12:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-988) Add API to manipulate
 JChannelFactory stacks member
Message-ID: <22228859.1244566736540.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add API to manipulate JChannelFactory stacks member
---------------------------------------------------

                 Key: JGRP-988
                 URL: https://jira.jboss.org/jira/browse/JGRP-988
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Brian Stansberry
            Assignee: Bela Ban
             Fix For: 2.6.11


I'd like to see the following methods added to JChannelFactory to go along with the existing getConfig and removeConfig.  These will allow the JBoss AS-specific subclass to update the contents of the "stacks" member in response to updates from management tools like the embedded console or Jopr:

public boolean addConfig(String stack_name, String config, boolean replace) {
   boolean added = replace;
   if(replace) {
       stacks.put(st_name, val);
       if(log.isTraceEnabled())
           log.trace("added config '" + st_name + "'");
    }
    else {
        if(!stacks.containsKey(st_name)) {
            stacks.put(st_name, val);
            added = true;
            if(log.isTraceEnabled())
               log.trace("added config '" + st_name + "'");
    }
    else {
         if(log.isTraceEnabled())
           log.trace("didn't add config '" + st_name + " because one of the same name already existed");
    }

    return added;
}

public Set<String> getConfigNames() {
   return Collections.unmodifiableSet(stacks.keySet());
}

Bela, I've assigned this to you to get your feedback on it, but I'd be happy to do it. Just assign back to me.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 13:09:09 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 9 Jun 2009 13:09:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7007) Upgrade AS TestSuite
	to JUnit 4.6
Message-ID: <24691632.1244567349279.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade AS TestSuite to JUnit 4.6
---------------------------------

                 Key: JBAS-7007
                 URL: https://jira.jboss.org/jira/browse/JBAS-7007
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-6.0.0.Alpha1


AS TestSuite is still in the dark ages of JUnit 3.x...upgrade time

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 13:43:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 9 Jun 2009 13:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6962)
 org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
In-Reply-To: <994948.1242838745393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33379167.1244569436552.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6962:
---------------------------------


The generated SQL looks fine except for the differences in the conditional AND expressions so looks like an adjustment to the test case as done in JBAS-5497.  

> org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
> ----------------------------------------------------------------------
>
>                 Key: JBAS-6962
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6962
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: TEST-org.jboss.test.cmp2.commerce.CompleteUnitTestCase.xml
>
>
> With IBM JDK 1.6 the test testJBossQL fails with this message:
> Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> junit.framework.AssertionFailedError: Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> 	at org.jboss.test.cmp2.commerce.QueryTest.testJBossQL(QueryTest.java:169)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)
> It's strange that with IBM 1.6 the failure does not happen in that test, but in different - testEJBQL:
> expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> junit.framework.ComparisonFailure: expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> 	at org.jboss.test.cmp2.commerce.QueryTest.testEJBQL(QueryTest.java:329)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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:193)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Tue Jun  9 13:46:08 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 9 Jun 2009 13:46:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-988) Add API to
 manipulate JChannelFactory stacks member
In-Reply-To: <22228859.1244566736540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1925425.1244569568958.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471274#action_12471274 ] 

Bela Ban commented on JGRP-988:
-------------------------------

I have no objection, but I'm questioning in general whether we should trash JChannelFactory. It is IMO pretty useless, new apps inject channels anyway, and that mechanism is external.
Can't we move this entire class into JBoss AS ? I'll definitely trash it in 3.0...

> Add API to manipulate JChannelFactory stacks member
> ---------------------------------------------------
>
>                 Key: JGRP-988
>                 URL: https://jira.jboss.org/jira/browse/JGRP-988
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Brian Stansberry
>            Assignee: Bela Ban
>             Fix For: 2.6.11
>
>
> I'd like to see the following methods added to JChannelFactory to go along with the existing getConfig and removeConfig.  These will allow the JBoss AS-specific subclass to update the contents of the "stacks" member in response to updates from management tools like the embedded console or Jopr:
> public boolean addConfig(String stack_name, String config, boolean replace) {
>    boolean added = replace;
>    if(replace) {
>        stacks.put(st_name, val);
>        if(log.isTraceEnabled())
>            log.trace("added config '" + st_name + "'");
>     }
>     else {
>         if(!stacks.containsKey(st_name)) {
>             stacks.put(st_name, val);
>             added = true;
>             if(log.isTraceEnabled())
>                log.trace("added config '" + st_name + "'");
>     }
>     else {
>          if(log.isTraceEnabled())
>            log.trace("didn't add config '" + st_name + " because one of the same name already existed");
>     }
>     return added;
> }
> public Set<String> getConfigNames() {
>    return Collections.unmodifiableSet(stacks.keySet());
> }
> Bela, I've assigned this to you to get your feedback on it, but I'd be happy to do it. Just assign back to me.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 13:55:56 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 9 Jun 2009 13:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-353) contribute xsd to xml
 catalog (xsd dependent on runtime)
Message-ID: <22572021.1244570156492.JavaMail.jira@cloud.prod.atl2.jboss.com>

contribute xsd to xml catalog (xsd dependent on runtime)
--------------------------------------------------------

                 Key: GPD-353
                 URL: https://jira.jboss.org/jira/browse/GPD-353
             Project: JBoss jBPM GPD
          Issue Type: Task
          Components: jpdl
            Reporter: Koen Aers
            Assignee: Koen Aers
             Fix For: jBPM jPDL Designer 4.0.0.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 14:23:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 9 Jun 2009 14:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JGRP-988) Add API to manipulate
 JChannelFactory stacks member
In-Reply-To: <22228859.1244566736540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21941429.1244571836857.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned JGRP-988:
-------------------------------------

    Assignee: Brian Stansberry  (was: Bela Ban)


I'd prefer to have the class in AS. The problem is JBC and JBM use the JGroups version, so the AS is forced to subclass it to be compatible.

I'll think about it a bit; if you aren't going to ever change this class I could simply move the entire impl into the AS class and almost treat the JGroups class as an interface. Save the JGroups project the hassle of making changes, putting them in releases etc.

> Add API to manipulate JChannelFactory stacks member
> ---------------------------------------------------
>
>                 Key: JGRP-988
>                 URL: https://jira.jboss.org/jira/browse/JGRP-988
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.6.11
>
>
> I'd like to see the following methods added to JChannelFactory to go along with the existing getConfig and removeConfig.  These will allow the JBoss AS-specific subclass to update the contents of the "stacks" member in response to updates from management tools like the embedded console or Jopr:
> public boolean addConfig(String stack_name, String config, boolean replace) {
>    boolean added = replace;
>    if(replace) {
>        stacks.put(st_name, val);
>        if(log.isTraceEnabled())
>            log.trace("added config '" + st_name + "'");
>     }
>     else {
>         if(!stacks.containsKey(st_name)) {
>             stacks.put(st_name, val);
>             added = true;
>             if(log.isTraceEnabled())
>                log.trace("added config '" + st_name + "'");
>     }
>     else {
>          if(log.isTraceEnabled())
>            log.trace("didn't add config '" + st_name + " because one of the same name already existed");
>     }
>     return added;
> }
> public Set<String> getConfigNames() {
>    return Collections.unmodifiableSet(stacks.keySet());
> }
> Bela, I've assigned this to you to get your feedback on it, but I'd be happy to do it. Just assign back to me.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 14:37:56 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 9 Jun 2009 14:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-289) Process Debugger
In-Reply-To: <24199398.1231385044241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1807252.1244572676590.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-289:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)


as predicted, move to post GA

> Process Debugger
> ----------------
>
>                 Key: GPD-289
>                 URL: https://jira.jboss.org/jira/browse/GPD-289
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> It should be possible to add breakpoints to the process definition. When the process is run from a unit test in debugging mode, the execution should stop at the appropriate breakpoint, giving the developer the possibility to inspect process variables, etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 15:36:56 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 9 Jun 2009 15:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7005) Logging categories
In-Reply-To: <4751763.1244554557239.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5735511.1244576216614.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved JBAS-7005.
--------------------------------

    Resolution: Done


Added additional category limits.  

This impacts what users have to do when enabling trace/debug (by changing the root logger).  To enable trace/debug for any of the classes covered by the category limits, they will also need to change the category limit to allow trace/debug.

> Logging categories
> ------------------
>
>                 Key: JBAS-7005
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7005
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Jesper Pedersen
>            Assignee: Scott Marlow
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The jboss-log4j.xml should contain categories to limit the logging of all classes used during startup.
> An example what is missing currently is
>    <!-- Limit Arjuna
>    <category name="com.arjuna">
>       <priority value="INFO"/>
>    </category>
>    -->

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 16:43:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 9 Jun 2009 16:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCLUSTER-237) Improve
 ClusterChooserInterceptor exception messages
Message-ID: <31712902.1244580236721.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve ClusterChooserInterceptor exception messages
----------------------------------------------------

                 Key: JBCLUSTER-237
                 URL: https://jira.jboss.org/jira/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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 17:29:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 9 Jun 2009 17:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6808) expose cluster
 partition name via some ManagedObject
In-Reply-To: <16044072.1240247602730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32536589.1244582996640.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved JBAS-6808.
------------------------------------

    Resolution: Done


> expose cluster partition name via some ManagedObject
> ----------------------------------------------------
>
>                 Key: JBAS-6808
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6808
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> In the as4 plugin, we exposed the following trait:
>           <metric property="partitionName" dataType="trait" displayType="summary"
>                   description="the name of the cluster partition this app server instance belongs to"/>
> which we obtained via JMX as follows:
>     private String getPartitionName() {
>         ObjectNameQueryUtility queryUtility = new ObjectNameQueryUtility(
>             "jboss:partitionName=%partitionName%,service=DistributedReplicantManager");
>         try {
>             List<EmsBean> mBeans = loadConnection().queryBeans(queryUtility.getTranslatedQuery());
>             if (mBeans.size() == 1) {
>                 if (queryUtility.setMatchedKeyValues(mBeans.get(0).getBeanName().getKeyProperties())) {
>                     return queryUtility.getVariableValues().get("partitionName");
>                 }
>             }
>         } catch (Exception e) {
>             log.error("Could not load partition name as connection could not be loaded");
>         }
>         return null;
>     }
> We need this value exposed via some ManagedObject so we can provide the same trait in the as5 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 18:29:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 9 Jun 2009 18:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-988) Add API to
 manipulate JChannelFactory stacks member
In-Reply-To: <22228859.1244566736540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13415995.1244586596440.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471312#action_12471312 ] 

Brian Stansberry commented on JGRP-988:
---------------------------------------

Sorry; that last comment was totally off-base. JBC uses the ChannelFactory interface, not the JChannelFactory class. I have a memory of needing to subclass for some reason, but perhaps I'm wrong; maybe the AS version just started off as a minor extension that has now grown so large it shouldn't be a subclass. I'll keep poking.

> Add API to manipulate JChannelFactory stacks member
> ---------------------------------------------------
>
>                 Key: JGRP-988
>                 URL: https://jira.jboss.org/jira/browse/JGRP-988
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.6.11
>
>
> I'd like to see the following methods added to JChannelFactory to go along with the existing getConfig and removeConfig.  These will allow the JBoss AS-specific subclass to update the contents of the "stacks" member in response to updates from management tools like the embedded console or Jopr:
> public boolean addConfig(String stack_name, String config, boolean replace) {
>    boolean added = replace;
>    if(replace) {
>        stacks.put(st_name, val);
>        if(log.isTraceEnabled())
>            log.trace("added config '" + st_name + "'");
>     }
>     else {
>         if(!stacks.containsKey(st_name)) {
>             stacks.put(st_name, val);
>             added = true;
>             if(log.isTraceEnabled())
>                log.trace("added config '" + st_name + "'");
>     }
>     else {
>          if(log.isTraceEnabled())
>            log.trace("didn't add config '" + st_name + " because one of the same name already existed");
>     }
>     return added;
> }
> public Set<String> getConfigNames() {
>    return Collections.unmodifiableSet(stacks.keySet());
> }
> Bela, I've assigned this to you to get your feedback on it, but I'd be happy to do it. Just assign back to me.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 22:13:07 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 9 Jun 2009 22:13:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6982) unable to connect
 to Profile Service remotely using EJB remote interface
In-Reply-To: <33034814.1243442816774.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29146894.1244599987101.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-6982.
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Resolution: Done


The required user was javaduke password = anotherduke, so I added admin user with password admin with the Adminstrator role as well. The org.jboss.test.profileservice.testsecure.ProfileServiceUnitTestCase which validates secured access via the ejbs.

> unable to connect to Profile Service remotely using EJB remote interface
> ------------------------------------------------------------------------
>
>                 Key: JBAS-6982
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6982
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The non-EJB remote interface is working, with the exception of the various class loading exceptions. The EJB interface is not, due to an authentication failure, but I think it used to work.
> Here's the log output showing me doing the JNDI lookup of the EJB proxies:
> DEBUG 27-05 12:40:03,988 (RemoteProfileServiceConnectionProvider.java:doConnect:90)  -Connecting to Profile Service via remote JNDI using env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:03,988 (AbstractProfileServiceConnectionProvider.java:createInitialContext:74)  -Creating JNDI InitialContext with env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:04,004 (Logger.java:debug:228)  -Using ThreadLocal: false
> DEBUG 27-05 12:40:04,035 (AbstractProfileServiceConnectionProvider.java:createInitialContext:83)  -Created JNDI InitialContext [javax.naming.InitialContext at 1ccb029].
> DEBUG 27-05 12:40:04,035 (Logger.java:debug:228)  -createSocket, hostAddr: /127.0.0.1, port: 1099, localAddr: null, localPort: 0, timeout: 0
> DEBUG 27-05 12:40:04,191 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureProfileService/remote
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Encrypted Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -removed SocketClientInvoker[3820e, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -Created Proxy of type $Proxy1 for EJB3 Business Interface: org.jboss.profileservice.spi.ProfileService
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureManagementView/remote
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -removed SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Created Proxy of type $Proxy3 for EJB3 Business Interface: org.jboss.deployers.spi.management.ManagementView
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureDeploymentManager/remote
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -removed SocketClientInvoker[12940b3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Created Proxy of type $Proxy5 for EJB3 Business Interface: org.jboss.deployers.spi.management.deploy.DeploymentManager
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Couldn't handle invocation directly within org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8: Current invocation "public abstract boolean org.jboss.deployers.spi.management.ManagementView.load()" is not eligible for direct handling by org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Received invocation request to method org.jboss.deployers.spi.management.ManagementView: org.jboss.deployers.spi.management.ManagementView.load(); using hash: -657996635075089079
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -removed SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] disconnecting ...
> And here's the "EJBAccessException: Caller unauthorized" that occurs when I call load() on the ManagementView proxy:
> Exception in thread "main" javax.ejb.EJBAccessException: Caller unauthorized
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:199)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         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:524)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 22:27:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 9 Jun 2009 22:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6979)
 org.jboss.dependency.spi.ControllerState class (from jboss-dependency.jar)
 required by remote Profile Service client calling
 ManagementView.getDeployment()
In-Reply-To: <28592167.1243393316467.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19416717.1244600876708.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-6979.
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Resolution: Rejected


No, jboss-dependency.jar is required as its a dependency of the  org.jboss.integration:jboss-profileservice-spi (jboss-profileservice-spi.jar) spi:

    <dependency>
      <groupId>org.jboss.microcontainer</groupId>
      <artifactId>jboss-dependency</artifactId>
    </dependency>


> org.jboss.dependency.spi.ControllerState class (from jboss-dependency.jar) required by remote Profile Service client calling ManagementView.getDeployment()
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6979
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6979
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> I'm assuming this class should not be required by a remote client.
> Here's the stack trace:
> 2009-05-26 22:41:31,357 WARN  [InventoryManager.discovery-1] (rhq.core.pc.inventory.InventoryManager)- Failure during discovery for [EJB3 JAR] Resources - failed after 156 ms.
> java.lang.Exception: Discovery component invocation failed.
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:248)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NoClassDefFoundError: org/jboss/dependency/spi/ControllerState
> 	at org.jboss.profileservice.spi.types.ControllerStateMetaType.<init>(ControllerStateMetaType.java:53)
> 	at org.jboss.profileservice.spi.types.ControllerStateMetaType.<clinit>(ControllerStateMetaType.java:49)
> 	at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> 	at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> 	at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> 	at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
> 	at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
> 	at java.lang.reflect.Field.getLong(Field.java:528)
> 	at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1614)
> 	at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
> 	at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:413)
> 	at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.managed.plugins.DefaultFieldsImpl.readObject(DefaultFieldsImpl.java:378)
> 	at sun.reflect.GeneratedMethodAccessor380.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.managed.plugins.ManagedPropertyImpl.readVersion1(ManagedPropertyImpl.java:652)
> 	at org.jboss.managed.plugins.ManagedPropertyImpl.readObject(ManagedPropertyImpl.java:626)
> 	at sun.reflect.GeneratedMethodAccessor379.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at AOPProxy$1.getDeployment(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.AbstractManagedDeploymentDiscoveryComponent.discoverResources(AbstractManagedDeploymentDiscoveryComponent.java:86)
> 	at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
> 	... 5 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.dependency.spi.ControllerState
> 	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 org.rhq.core.pc.plugin.ChildFirstPluginClassLoader.loadClass(ChildFirstPluginClassLoader.java:68)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> 	... 87 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 22:42:56 2009
From: jira-events at lists.jboss.org (Tihomir Surdilovic (JIRA))
Date: Tue, 9 Jun 2009 22:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAOP-45) callfield pointcut
Message-ID: <17519801.1244601776646.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAOP-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tihomir Surdilovic reassigned JBAOP-45:
---------------------------------------

    Assignee:     (was: Tihomir Surdilovic)


> callfield pointcut
> ------------------
>
>                 Key: JBAOP-45
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-45
>             Project: JBoss AOP
>          Issue Type: Feature Request
>    Affects Versions: 2.1.0.CR1
>            Reporter: Bill Burke
>             Fix For: 2.2.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 22:42:57 2009
From: jira-events at lists.jboss.org (Tihomir Surdilovic (JIRA))
Date: Tue, 9 Jun 2009 22:42:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAOP-576) Optimize
 recalculating caller chains when adding a binding
In-Reply-To: <7732724.1211215679818.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6241403.1244601777130.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAOP-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tihomir Surdilovic reassigned JBAOP-576:
----------------------------------------

    Assignee:     (was: Tihomir Surdilovic)


> Optimize recalculating caller chains when adding a binding
> ----------------------------------------------------------
>
>                 Key: JBAOP-576
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-576
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>             Fix For: 2.2.0.GA
>
>
> Should just need to recalculate that particular binding similar to what was done for JBAOP-575

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 22:42:56 2009
From: jira-events at lists.jboss.org (Tihomir Surdilovic (JIRA))
Date: Tue, 9 Jun 2009 22:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAOP-577) Optimize adding
 aspect bindings to instance advisors
In-Reply-To: <8024818.1211215859308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18610424.1244601776870.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAOP-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tihomir Surdilovic reassigned JBAOP-577:
----------------------------------------

    Assignee:     (was: Tihomir Surdilovic)


> Optimize adding aspect bindings to instance advisors
> ----------------------------------------------------
>
>                 Key: JBAOP-577
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-577
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>             Fix For: 2.2.0.GA
>
>
> With the changes from JBAOP-575, it seems that the chains are still fully calculated when woven with GeneratedAdvisorInstrumentor if added for an instance. Run org.jboss.test.aop.dynamicgenadvisor.DynamicTester.testSimpleInstanceUsingDomainForMethod() and testInstanceUsingDomainForMethod() in a debugger to see what I mean

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun  9 23:05:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 9 Jun 2009 23:05:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6980)
 "ClassNotFoundException:
 org.jboss.aop.instrument.Untransformable" occurs when
 ManagementView.getComponentsForType(<MBean:WebApplication>) is called from
 a remote client
In-Reply-To: <15938916.1243426198456.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17054095.1244603157055.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-6980.
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Resolution: Done


The CtClass.toClass call is outside of the profile service layer, so there is not anything I can do here. 

> "ClassNotFoundException: org.jboss.aop.instrument.Untransformable" occurs when ManagementView.getComponentsForType(<MBean:WebApplication>) is called from a remote client
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6980
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6980
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Note, this occurs even though I have jboss-aop-client.jar, which contains org.jboss.aop.instrument.Untransformable, in my client's classpath. Here's the stack trace:
> 2009-05-27 07:54:31,035 WARN  [InventoryManager.discovery-1] (rhq.core.pc.inventory.InventoryManager)- Failure during discovery for [Embedded Web Application Context] Resources - failed after 250 ms.
> java.lang.Exception: Discovery component invocation failed.
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:248)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.IllegalStateException: org.jboss.remoting.InvocationFailureException: Unable to perform invocation; nested exception is: 
> 	java.lang.RuntimeException: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:160)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:141)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.getWebApplicationComponents(WebApplicationContextDiscoveryComponent.java:182)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.discoverResources(WebApplicationContextDiscoveryComponent.java:90)
> 	at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
> 	... 5 more
> Caused by: org.jboss.remoting.InvocationFailureException: Unable to perform invocation; nested exception is: 
> 	java.lang.RuntimeException: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:142)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:891)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	... 12 more
> Caused by: java.lang.RuntimeException: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at org.jboss.aop.proxy.MarshalledInterfaceProxy.readResolve(MarshalledInterfaceProxy.java:76)
> 	at sun.reflect.GeneratedMethodAccessor973.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:141)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.getWebApplicationComponents(WebApplicationContextDiscoveryComponent.java:182)
> 	at org.rhq.plugins.jbossas5.WebApplicationContextDiscoveryComponent.discoverResources(WebApplicationContextDiscoveryComponent.java:90)
> 	at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	... 19 more
> Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at javassist.ClassPool.toClass(ClassPool.java:1035)
> 	at javassist.scopedpool.ScopedClassPool.toClass(ScopedClassPool.java:306)
> 	at javassist.CtClass.toClass(CtClass.java:1094)
> 	at org.jboss.aop.instrument.TransformerCommon$ToClassAction$2.toClass(TransformerCommon.java:331)
> 	at org.jboss.aop.instrument.TransformerCommon.toClass(TransformerCommon.java:139)
> 	at org.jboss.aop.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:126)
> 	at org.jboss.aop.proxy.ProxyFactory.createInterfaceProxy(ProxyFactory.java:96)
> 	at org.jboss.aop.proxy.MarshalledInterfaceProxy.readResolve(MarshalledInterfaceProxy.java:72)
> 	at sun.reflect.GeneratedMethodAccessor973.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	... 19 more
> Caused by: java.lang.NoClassDefFoundError: org/jboss/aop/instrument/Untransformable
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
> 	at sun.reflect.GeneratedMethodAccessor974.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at javassist.ClassPool.toClass2(ClassPool.java:1047)
> 	at javassist.ClassPool.toClass(ClassPool.java:1029)
> 	... 82 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.aop.instrument.Untransformable
> 	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)
> 	... 89 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 01:10:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 01:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6984) trying to remotely
 retrieve
 statistic properties (e.g. rollbackCount) from MCBean:JTA managed
 components results in "ClassNotFoundException:
 com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
In-Reply-To: <11628190.1243511107980.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16274441.1244610656808.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471333#action_12471333 ] 

Scott M Stark commented on JBAS-6984:
-------------------------------------

A new release of jboss-managed is needed to address JBMAN-86, and JBMAN-87

> trying to remotely retrieve statistic properties (e.g. rollbackCount) from MCBean:JTA managed components results in "ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6984
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6984
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>
> 2009-05-28 07:40:01,544 ERROR [ResourceContainer.invoker.daemon-364] (org.rhq.plugins.jbossas5.ApplicationServerComponent)- Failed to obtain metric 'MCBean|JTA|*|rollbackCount'.
> java.lang.IllegalStateException: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:160)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
> 	at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
> 	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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> 	at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1462)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1312)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	... 11 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 01:09:37 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 01:09:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-86) ManagedObjectImpl
 annotations should not be serialized
Message-ID: <27322704.1244610577440.JavaMail.jira@cloud.prod.atl2.jboss.com>

ManagedObjectImpl annotations should not be serialized
------------------------------------------------------

                 Key: JBMAN-86
                 URL: https://jira.jboss.org/jira/browse/JBMAN-86
             Project: JBoss Managed
          Issue Type: Bug
          Components: managedobject
    Affects Versions: JBossMan.2.1.1.Beta2
            Reporter: Scott M Stark
            Assignee: Scott M Stark


The annotations associated with ManagedObjectImpl should not be serialized as they can contain server side objects

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 01:10:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 01:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-87) DefaultFieldsImpl
 should not serialize annotations
Message-ID: <6682940.1244610656615.JavaMail.jira@cloud.prod.atl2.jboss.com>

DefaultFieldsImpl should not serialize annotations
--------------------------------------------------

                 Key: JBMAN-87
                 URL: https://jira.jboss.org/jira/browse/JBMAN-87
             Project: JBoss Managed
          Issue Type: Bug
          Components: managedobject
    Affects Versions: JBossMan.2.1.1.Beta2
            Reporter: Scott M Stark
            Assignee: Scott M Stark


Fields annotations should not be serialized as they in general will reference server side objects

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 01:56:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 01:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-86) ManagedObjectImpl
 annotations should not be serialized
In-Reply-To: <27322704.1244610577440.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24625268.1244613416477.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMAN-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBMAN-86.
--------------------------------

    Fix Version/s: JBossMan.2.1.1.Beta3
       Resolution: Done


> ManagedObjectImpl annotations should not be serialized
> ------------------------------------------------------
>
>                 Key: JBMAN-86
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-86
>             Project: JBoss Managed
>          Issue Type: Bug
>          Components: managedobject
>    Affects Versions: JBossMan.2.1.1.Beta2
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossMan.2.1.1.Beta3
>
>
> The annotations associated with ManagedObjectImpl should not be serialized as they can contain server side objects

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 02:20:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Wed, 10 Jun 2009 02:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMICROCONT-444) Create a
 jboss-service.xml->jboss-beans.xml migration tool
Message-ID: <14408672.1244614856430.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create a jboss-service.xml->jboss-beans.xml migration tool
----------------------------------------------------------

                 Key: JBMICROCONT-444
                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-444
             Project: JBoss Microcontainer
          Issue Type: Feature Request
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: JBossMC-2.0.x


Create a tool that converts jboss-service.xml files to jboss-beans.xml. 
This tool should at a minimum cover the most commonly used features of a jboss-service.xml file.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 02:18:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 02:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6984) trying to remotely
 retrieve
 statistic properties (e.g. rollbackCount) from MCBean:JTA managed
 components results in "ClassNotFoundException:
 com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
In-Reply-To: <11628190.1243511107980.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19236551.1244614736816.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-6984.
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Resolution: Done


jboss-managed 2.1.1.Beta3 no longer serializes the annotations that look to be causing this problem.

> trying to remotely retrieve statistic properties (e.g. rollbackCount) from MCBean:JTA managed components results in "ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6984
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6984
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> 2009-05-28 07:40:01,544 ERROR [ResourceContainer.invoker.daemon-364] (org.rhq.plugins.jbossas5.ApplicationServerComponent)- Failed to obtain metric 'MCBean|JTA|*|rollbackCount'.
> java.lang.IllegalStateException: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:160)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.ClassNotFoundException: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
> 	at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
> 	at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
> 	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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> 	at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1462)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1312)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashMap.readObject(HashMap.java:1030)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at java.util.HashSet.readObject(HashSet.java:291)
> 	at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
> 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
> 	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
> 	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
> 	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:64)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:183)
> 	at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:506)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
> 	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:156)
> 	... 11 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 02:31:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 02:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-87) DefaultFieldsImpl
 should not serialize annotations
In-Reply-To: <6682940.1244610656615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12083396.1244615516442.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMAN-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBMAN-87.
--------------------------------

    Fix Version/s: JBossMan.2.1.1.Beta3
       Resolution: Done


> DefaultFieldsImpl should not serialize annotations
> --------------------------------------------------
>
>                 Key: JBMAN-87
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-87
>             Project: JBoss Managed
>          Issue Type: Bug
>          Components: managedobject
>    Affects Versions: JBossMan.2.1.1.Beta2
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossMan.2.1.1.Beta3
>
>
> Fields annotations should not be serialized as they in general will reference server side objects

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 02:48:09 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 02:48:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-5452)
 ManagementView.getDeployment
 should always at least return a structural view of a deployment
In-Reply-To: <8840076.1208274234767.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17468536.1244616489014.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-5452.
---------------------------------

    Resolution: Done


For the various deployment types there is a default behavior that is creating a ManagedDeployment. Looking at the output from the 
http://localhost:8080/jmx-console/ProfileServiceDebugServlet, it looks like every deployment has a ManagedDeployment.

listDeploymentTree Results

ManagedDeployment: //localhost/
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=default, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=default, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:host=localhost,path=/,type=Manager, type=(ComponentType{type=MBean, subtype=WebApplicationManager}), compName=jboss.web:host=localhost,path=/,type=Manager, attachment: null
++++++ properties: [sessionIdLength, maxInactiveInterval, expiredSessions, entropy, sessionCounter, maxActiveSessions, className, processingTime, algorithm, processExpiresFrequency, rejectedSessions, sessionAverageAliveTime, randomFile, modelerType, duplicates, pathname, sessionMaxAliveTime, activeSessions, name, maxActive, distributable]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=jsp, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=jsp, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/, type=(ComponentType{type=MBean, subtype=WebApplication}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/, attachment: null
++++++ properties: [privileged, compilerClasspath, crossContext, swallowOutput, antiResourceLocking, caseSensitive, cookies, workDir, loader, unloadDelay, path, managedResource, objectName, servlets, tldScanTime, realm, namingContextListener, configFile, modelerType, saveConfig, stateManageable, state, eventProvider, cacheTTL, cachingAllowed, cacheObjectMaxSize, startupTime, statisticsProvider, javaVMs, manager, staticResources, override, docBase, defaultContextXml, server, startTime, defaultWebXml, deploymentDescriptor, mappingObject, parentClassLoader, processingTime, useNaming, delegate, antiJARLocking, valveObjectNames, cacheMaxSize, logger, engineName, allowLinking, children, reloadable, welcomeFiles]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=Status Servlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=Status Servlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
ManagedDeployment: //localhost/admin-console
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/admin-console,j2eeType=Servlet,name=Faces Servlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/admin-console,j2eeType=Servlet,name=Faces Servlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/admin-console, type=(ComponentType{type=MBean, subtype=WebApplication}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/admin-console, attachment: null
++++++ properties: [privileged, compilerClasspath, crossContext, swallowOutput, antiResourceLocking, caseSensitive, cookies, workDir, loader, unloadDelay, path, managedResource, objectName, servlets, tldScanTime, realm, namingContextListener, configFile, modelerType, saveConfig, stateManageable, state, eventProvider, cacheTTL, cachingAllowed, cacheObjectMaxSize, startupTime, statisticsProvider, javaVMs, manager, staticResources, override, docBase, defaultContextXml, server, startTime, defaultWebXml, deploymentDescriptor, mappingObject, parentClassLoader, processingTime, useNaming, delegate, antiJARLocking, valveObjectNames, cacheMaxSize, logger, engineName, allowLinking, children, reloadable, welcomeFiles]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/admin-console,j2eeType=Servlet,name=default, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/admin-console,j2eeType=Servlet,name=default, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/admin-console,j2eeType=Servlet,name=jsp, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/admin-console,j2eeType=Servlet,name=jsp, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:host=localhost,path=/admin-console,type=Manager, type=(ComponentType{type=MBean, subtype=WebApplicationManager}), compName=jboss.web:host=localhost,path=/admin-console,type=Manager, attachment: null
++++++ properties: [sessionIdLength, maxInactiveInterval, expiredSessions, entropy, sessionCounter, maxActiveSessions, className, processingTime, algorithm, processExpiresFrequency, rejectedSessions, sessionAverageAliveTime, randomFile, modelerType, duplicates, pathname, sessionMaxAliveTime, activeSessions, name, maxActive, distributable]
ManagedDeployment: //localhost/invoker
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=ReadOnlyJNDIFactory, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=ReadOnlyJNDIFactory, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/invoker, type=(ComponentType{type=MBean, subtype=WebApplication}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/invoker, attachment: null
++++++ properties: [privileged, compilerClasspath, crossContext, swallowOutput, antiResourceLocking, caseSensitive, cookies, workDir, loader, unloadDelay, path, managedResource, objectName, servlets, tldScanTime, realm, namingContextListener, configFile, modelerType, saveConfig, stateManageable, state, eventProvider, cacheTTL, cachingAllowed, cacheObjectMaxSize, startupTime, statisticsProvider, javaVMs, manager, staticResources, override, docBase, defaultContextXml, server, startTime, defaultWebXml, deploymentDescriptor, mappingObject, parentClassLoader, processingTime, useNaming, delegate, antiJARLocking, valveObjectNames, cacheMaxSize, logger, engineName, allowLinking, children, reloadable, welcomeFiles]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=default, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=default, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=JNDIFactory, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=JNDIFactory, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=JMXInvokerServlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=JMXInvokerServlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=EJBInvokerServlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=EJBInvokerServlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=jsp, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/invoker,j2eeType=Servlet,name=jsp, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:host=localhost,path=/invoker,type=Manager, type=(ComponentType{type=MBean, subtype=WebApplicationManager}), compName=jboss.web:host=localhost,path=/invoker,type=Manager, attachment: null
++++++ properties: [sessionIdLength, maxInactiveInterval, expiredSessions, entropy, sessionCounter, maxActiveSessions, className, processingTime, algorithm, processExpiresFrequency, rejectedSessions, sessionAverageAliveTime, randomFile, modelerType, duplicates, pathname, sessionMaxAliveTime, activeSessions, name, maxActive, distributable]
ManagedDeployment: //localhost/jbossws
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=ContextServlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=ContextServlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/jbossws, type=(ComponentType{type=MBean, subtype=WebApplication}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/jbossws, attachment: null
++++++ properties: [privileged, compilerClasspath, crossContext, swallowOutput, antiResourceLocking, caseSensitive, cookies, workDir, loader, unloadDelay, path, managedResource, objectName, servlets, tldScanTime, realm, namingContextListener, configFile, modelerType, saveConfig, stateManageable, state, eventProvider, cacheTTL, cachingAllowed, cacheObjectMaxSize, startupTime, statisticsProvider, javaVMs, manager, staticResources, override, docBase, defaultContextXml, server, startTime, defaultWebXml, deploymentDescriptor, mappingObject, parentClassLoader, processingTime, useNaming, delegate, antiJARLocking, valveObjectNames, cacheMaxSize, logger, engineName, allowLinking, children, reloadable, welcomeFiles]
+++ ManagedComponent(name=jboss.web:host=localhost,path=/jbossws,type=Manager, type=(ComponentType{type=MBean, subtype=WebApplicationManager}), compName=jboss.web:host=localhost,path=/jbossws,type=Manager, attachment: null
++++++ properties: [sessionIdLength, maxInactiveInterval, expiredSessions, entropy, sessionCounter, maxActiveSessions, className, processingTime, algorithm, processExpiresFrequency, rejectedSessions, sessionAverageAliveTime, randomFile, modelerType, duplicates, pathname, sessionMaxAliveTime, activeSessions, name, maxActive, distributable]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=PortComponentLinkServlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=PortComponentLinkServlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=jsp, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=jsp, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=default, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jbossws,j2eeType=Servlet,name=default, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
ManagedDeployment: //localhost/jmx-console
+++ ManagedComponent(name=jboss.web:host=localhost,path=/jmx-console,type=Manager, type=(ComponentType{type=MBean, subtype=WebApplicationManager}), compName=jboss.web:host=localhost,path=/jmx-console,type=Manager, attachment: null
++++++ properties: [sessionIdLength, maxInactiveInterval, expiredSessions, entropy, sessionCounter, maxActiveSessions, className, processingTime, algorithm, processExpiresFrequency, rejectedSessions, sessionAverageAliveTime, randomFile, modelerType, duplicates, pathname, sessionMaxAliveTime, activeSessions, name, maxActive, distributable]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/jmx-console, type=(ComponentType{type=MBean, subtype=WebApplication}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/jmx-console, attachment: null
++++++ properties: [privileged, compilerClasspath, crossContext, swallowOutput, antiResourceLocking, caseSensitive, cookies, workDir, loader, unloadDelay, path, managedResource, objectName, servlets, tldScanTime, realm, namingContextListener, configFile, modelerType, saveConfig, stateManageable, state, eventProvider, cacheTTL, cachingAllowed, cacheObjectMaxSize, startupTime, statisticsProvider, javaVMs, manager, staticResources, override, docBase, defaultContextXml, server, startTime, defaultWebXml, deploymentDescriptor, mappingObject, parentClassLoader, processingTime, useNaming, delegate, antiJARLocking, valveObjectNames, cacheMaxSize, logger, engineName, allowLinking, children, reloadable, welcomeFiles]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=DisplayOpResult, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=DisplayOpResult, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=jsp, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=jsp, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=ProfileServiceDebugServlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=ProfileServiceDebugServlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=default, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=default, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=DisplayMBeans, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=DisplayMBeans, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=InspectMBean, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=InspectMBean, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=ClusterView, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=ClusterView, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=ClusteredConsoleServlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=ClusteredConsoleServlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=HtmlAdaptor, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/jmx-console,j2eeType=Servlet,name=HtmlAdaptor, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
ManagedDeployment: //localhost/web-console
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=default, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=default, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Create String Threshold Monitor, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Create String Threshold Monitor, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/web-console, type=(ComponentType{type=MBean, subtype=WebApplication}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/web-console, attachment: null
++++++ properties: [privileged, compilerClasspath, crossContext, swallowOutput, antiResourceLocking, caseSensitive, cookies, workDir, loader, unloadDelay, path, managedResource, objectName, servlets, tldScanTime, realm, namingContextListener, configFile, modelerType, saveConfig, stateManageable, state, eventProvider, cacheTTL, cachingAllowed, cacheObjectMaxSize, startupTime, statisticsProvider, javaVMs, manager, staticResources, override, docBase, defaultContextXml, server, startTime, defaultWebXml, deploymentDescriptor, mappingObject, parentClassLoader, processingTime, useNaming, delegate, antiJARLocking, valveObjectNames, cacheMaxSize, logger, engineName, allowLinking, children, reloadable, welcomeFiles]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 Domains and Servers, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 Domains and Servers, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=HTTP Invocation, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=HTTP Invocation, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:host=localhost,path=/web-console,type=Manager, type=(ComponentType{type=MBean, subtype=WebApplicationManager}), compName=jboss.web:host=localhost,path=/web-console,type=Manager, attachment: null
++++++ properties: [sessionIdLength, maxInactiveInterval, expiredSessions, entropy, sessionCounter, maxActiveSessions, className, processingTime, algorithm, processExpiresFrequency, rejectedSessions, sessionAverageAliveTime, randomFile, modelerType, duplicates, pathname, sessionMaxAliveTime, activeSessions, name, maxActive, distributable]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=J2EEFolder, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=J2EEFolder, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 J2EE Apps, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 J2EE Apps, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=UCLs, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=UCLs, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=SystemFolder, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=SystemFolder, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Manage Threshold Monitor, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Manage Threshold Monitor, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=MBeans, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=MBeans, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Create Threshold Monitor, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Create Threshold Monitor, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=AOPFolder, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=AOPFolder, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Clear Monitor Alerts, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Clear Monitor Alerts, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Acknowledge Active Alarms, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Acknowledge Active Alarms, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Manage Snapshot, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Manage Snapshot, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Status Servlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Status Servlet, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 WebModule, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 WebModule, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Manage String Threshold Monitor, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Manage String Threshold Monitor, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Create Snapshot, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=Create Snapshot, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 EJBModules and EJBs, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JSR77 EJBModules and EJBs, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=MonitorsFolder, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=MonitorsFolder, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JMS Message, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=JMS Message, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
+++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=jsp, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/web-console,j2eeType=Servlet,name=jsp, attachment: null
++++++ properties: [objectName, minTime, statisticsProvider, loadTime, classLoadTime, processingTime, requestCount, modelerType, errorCount, stateManageable, eventProvider, engineName, maxTime]
ManagedDeployment: GarbageCollectorMXBeans
+++ ManagedComponent(name=java.lang:type=GarbageCollectorCopy, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.GarbageCollectorMXBean
++++++ properties: [memoryPoolNames, collectionCount, valid, name, collectionTime]
+++ ManagedComponent(name=java.lang:type=GarbageCollectorMarkSweepCompact, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.GarbageCollectorMXBean
++++++ properties: [memoryPoolNames, collectionCount, valid, name, collectionTime]
ManagedDeployment: JDK PlatformMBeans
+++ ManagedComponent(name=java.lang:type=Threading, type=(ComponentType{type=MBean, subtype=Platform}), compName=java.lang:type=Threading, attachment: java.lang.management.ThreadMXBean
++++++ properties: [daemonThreadCount, threadCount, threadContentionMonitoringSupported, totalStartedThreadCount, threadCpuTimeSupported, threadCpuTimeEnabled, currentThreadCpuTime, currentThreadUserTime, peakThreadCount, allThreadIds, currentThreadCpuTimeSupported, threadContentionMonitoringEnabled]
+++ ManagedComponent(name=java.lang:type=Memory, type=(ComponentType{type=MBean, subtype=Platform}), compName=java.lang:type=Memory, attachment: java.lang.management.MemoryMXBean
++++++ properties: [heapMemoryUsage, nonHeapMemoryUsage, verbose, objectPendingFinalizationCount]
+++ ManagedComponent(name=java.lang:type=OperatingSystem, type=(ComponentType{type=MBean, subtype=Platform}), compName=java.lang:type=OperatingSystem, attachment: java.lang.management.OperatingSystemMXBean
++++++ properties: [arch, availableProcessors, name, version]
+++ ManagedComponent(name=java.lang:type=Runtime, type=(ComponentType{type=MBean, subtype=Platform}), compName=java.lang:type=Runtime, attachment: java.lang.management.RuntimeMXBean
++++++ properties: [managementSpecVersion, bootClassPathSupported, bootClassPath, uptime, specVersion, specName, vmVersion, vmName, inputArguments, systemProperties, startTime, classPath, name, libraryPath, specVendor, vmVendor]
+++ ManagedComponent(name=java.lang:type=ClassLoading, type=(ComponentType{type=MBean, subtype=Platform}), compName=java.lang:type=ClassLoading, attachment: java.lang.management.ClassLoadingMXBean
++++++ properties: [totalLoadedClassCount, unloadedClassCount, verbose, loadedClassCount]
ManagedDeployment: MemoryManagerMXBeans
+++ ManagedComponent(name=java.lang:type=MemoryManagerCopy, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryManagerMXBean
++++++ properties: [memoryPoolNames, valid, name]
+++ ManagedComponent(name=java.lang:type=MemoryManagerCodeCacheManager, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryManagerMXBean
++++++ properties: [memoryPoolNames, valid, name]
+++ ManagedComponent(name=java.lang:type=MemoryManagerMarkSweepCompact, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryManagerMXBean
++++++ properties: [memoryPoolNames, valid, name]
ManagedDeployment: MemoryPoolMXBeans
+++ ManagedComponent(name=java.lang:type=MemoryPoolSurvivor Space, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryPoolMXBean
++++++ properties: [collectionUsageThreshold, usageThresholdCount, type, collectionUsageThresholdCount, valid, collectionUsageThresholdExceeded, usageThresholdSupported, collectionUsage, usageThreshold, usageThresholdExceeded, memoryManagerNames, usage, peakUsage, collectionUsageThresholdSupported, name]
+++ ManagedComponent(name=java.lang:type=MemoryPoolCode Cache, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryPoolMXBean
++++++ properties: [collectionUsageThreshold, usageThresholdCount, type, collectionUsageThresholdCount, valid, collectionUsageThresholdExceeded, usageThresholdSupported, collectionUsage, usageThreshold, usageThresholdExceeded, memoryManagerNames, usage, peakUsage, collectionUsageThresholdSupported, name]
+++ ManagedComponent(name=java.lang:type=MemoryPoolTenured Gen, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryPoolMXBean
++++++ properties: [collectionUsageThreshold, usageThresholdCount, type, collectionUsageThresholdCount, valid, collectionUsageThresholdExceeded, usageThresholdSupported, collectionUsage, usageThreshold, usageThresholdExceeded, memoryManagerNames, usage, peakUsage, collectionUsageThresholdSupported, name]
+++ ManagedComponent(name=java.lang:type=MemoryPoolPerm Gen, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryPoolMXBean
++++++ properties: [collectionUsageThreshold, usageThresholdCount, type, collectionUsageThresholdCount, valid, collectionUsageThresholdExceeded, usageThresholdSupported, collectionUsage, usageThreshold, usageThresholdExceeded, memoryManagerNames, usage, peakUsage, collectionUsageThresholdSupported, name]
+++ ManagedComponent(name=java.lang:type=MemoryPoolEden Space, type=(ComponentType{type=MBean, subtype=Platform}), compName=null, attachment: java.lang.management.MemoryPoolMXBean
++++++ properties: [collectionUsageThreshold, usageThresholdCount, type, collectionUsageThresholdCount, valid, collectionUsageThresholdExceeded, usageThresholdSupported, collectionUsage, usageThreshold, usageThresholdExceeded, memoryManagerNames, usage, peakUsage, collectionUsageThresholdSupported, name]
ManagedDeployment: ajp-127.0.0.1-8009
+++ ManagedComponent(name=jboss.web:name=ajp-127.0.0.1-8009,type=GlobalRequestProcessor, type=(ComponentType{type=MBean, subtype=WebRequestProcessor}), compName=jboss.web:name=ajp-127.0.0.1-8009,type=GlobalRequestProcessor, attachment: null
++++++ properties: [modelerType, bytesReceived, errorCount, bytesSent, processingTime, requestCount, maxTime]
+++ ManagedComponent(name=jboss.web:name=ajp-127.0.0.1-8009,type=ThreadPool, type=(ComponentType{type=MBean, subtype=WebThreadPool}), compName=jboss.web:name=ajp-127.0.0.1-8009,type=ThreadPool, attachment: null
++++++ properties: [maxThreads, backlog, currentThreadsBusy, acceptorThreadCount, threadPriority, paused, port, tcpNoDelay, soLinger, modelerType, soTimeout, daemon, running, currentThreadCount, name]
ManagedDeployment: file:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/bootstrap/aop.xml
+++ ManagedComponent(name=AOPJBossIntegration, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPJBossIntegration, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AOPClassPoolFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPClassPoolFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=aop-classloader:0.0.0$MODULE, type=(ComponentType{type=MCBean, subtype=*}), compName=aop-classloader:0.0.0$MODULE, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=aop-classloader:0.0.0, type=(ComponentType{type=MCBean, subtype=*}), compName=aop-classloader:0.0.0, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=DefaultAspectManager, type=(ComponentType{type=MCBean, subtype=*}), compName=DefaultAspectManager, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AOPClassLoaderScopingPolicy, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPClassLoaderScopingPolicy, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AspectManager, type=(ComponentType{type=MCBean, subtype=*}), compName=AspectManager, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AOPRegisterModuleCallback, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPRegisterModuleCallback, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
ManagedDeployment: file:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/bootstrap/classloader.xml
+++ ManagedComponent(name=bootstrap-classloader:0.0.0$MODULE, type=(ComponentType{type=MCBean, subtype=*}), compName=bootstrap-classloader:0.0.0$MODULE, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ClassLoaderSystem, type=(ComponentType{type=MCBean, subtype=*}), compName=ClassLoaderSystem, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ClassLoading, type=(ComponentType{type=MCBean, subtype=*}), compName=ClassLoading, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=bootstrap-classloader:0.0.0, type=(ComponentType{type=MCBean, subtype=*}), compName=bootstrap-classloader:0.0.0, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
ManagedDeployment: file:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/bootstrap/deployers.xml
+++ ManagedComponent(name=AOPXMLMetaDataParserDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPXMLMetaDataParserDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ClassLoadingMetaDataParser, type=(ComponentType{type=MCBean, subtype=*}), compName=ClassLoadingMetaDataParser, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ServiceMetaDataICF, type=(ComponentType{type=MCBean, subtype=*}), compName=ServiceMetaDataICF, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AOPAnnotationMetaDataParserDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPAnnotationMetaDataParserDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JARStructure, type=(ComponentType{type=MCBean, subtype=*}), compName=JARStructure, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=Deployers, type=(ComponentType{type=MCBean, subtype=*}), compName=Deployers, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=MainDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=MainDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ClassLoaderDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ClassLoaderDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AOPDeploymentAopMetaDataDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPDeploymentAopMetaDataDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=StructureBuilder, type=(ComponentType{type=MCBean, subtype=*}), compName=StructureBuilder, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=BeanDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=BeanDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=deployers-classloader:0.0.0, type=(ComponentType{type=MCBean, subtype=*}), compName=deployers-classloader:0.0.0, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=SARDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=SARDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=FileStructure, type=(ComponentType{type=MCBean, subtype=*}), compName=FileStructure, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=BeansDeploymentAopMetaDataDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=BeansDeploymentAopMetaDataDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=KernelDeploymentManagedObjectCreator, type=(ComponentType{type=MCBean, subtype=*}), compName=KernelDeploymentManagedObjectCreator, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=BeanMetaDataDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=BeanMetaDataDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=DeclaredStructure, type=(ComponentType{type=MCBean, subtype=*}), compName=DeclaredStructure, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=KernelDeploymentDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=KernelDeploymentDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ServiceDeploymentDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ServiceDeploymentDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ServiceDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ServiceDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=StructuralDeployers, type=(ComponentType{type=MCBean, subtype=*}), compName=StructuralDeployers, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=BeanMetaDataICF, type=(ComponentType{type=MCBean, subtype=*}), compName=BeanMetaDataICF, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JARFilter, type=(ComponentType{type=MCBean, subtype=*}), compName=JARFilter, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ClassLoadingDefaultDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ClassLoadingDefaultDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ClassLoaderClassPathDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ClassLoaderClassPathDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ClassLoaderDescribeDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ClassLoaderDescribeDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JARStructureCandidates, type=(ComponentType{type=MCBean, subtype=*}), compName=JARStructureCandidates, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AOPClassLoaderDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=AOPClassLoaderDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ManagedObjectCreator, type=(ComponentType{type=MCBean, subtype=*}), compName=ManagedObjectCreator, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ManagedDeploymentCreator, type=(ComponentType{type=MCBean, subtype=*}), compName=ManagedDeploymentCreator, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=deployers-classloader:0.0.0$MODULE, type=(ComponentType{type=MCBean, subtype=*}), compName=deployers-classloader:0.0.0$MODULE, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ModificationTypeStructureProcessor, type=(ComponentType{type=MCBean, subtype=*}), compName=ModificationTypeStructureProcessor, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ServiceClassLoaderDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ServiceClassLoaderDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=InMemoryClassesDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=InMemoryClassesDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
ManagedDeployment: file:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/bootstrap/jmx.xml
+++ ManagedComponent(name=JMXStartStopAdvice, type=(ComponentType{type=MCBean, subtype=*}), compName=JMXStartStopAdvice, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=jboss.system:type=ServerInfo, type=(ComponentType{type=MCBean, subtype=ServerInfo}), compName=jboss.system:type=ServerInfo, attachment: org.jboss.system.server.ServerInfo
++++++ properties: [maxMemory, OSArch, hostAddress, freeMemory, activeThreadGroupCount, OSVersion, javaVMName, totalMemory, activeThreadCount, alias, hostName, javaVMVendor, javaVendor, state, availableProcessors, javaVMVersion, OSName, javaVersion]
+++ ManagedComponent(name=JMXCreateDestroyAdvice, type=(ComponentType{type=MCBean, subtype=*}), compName=JMXCreateDestroyAdvice, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=jmx-classloader:0.0.0, type=(ComponentType{type=MCBean, subtype=*}), compName=jmx-classloader:0.0.0, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JMXRegistrationAdvice, type=(ComponentType{type=MCBean, subtype=*}), compName=JMXRegistrationAdvice, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JMXStartStopAdvice$AspectBinding, type=(ComponentType{type=MCBean, subtype=*}), compName=JMXStartStopAdvice$AspectBinding, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JMXKernel, type=(ComponentType{type=MCBean, subtype=*}), compName=JMXKernel, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=jmx-classloader:0.0.0$MODULE, type=(ComponentType{type=MCBean, subtype=*}), compName=jmx-classloader:0.0.0$MODULE, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JMXRegistrationAdvice$AspectBinding, type=(ComponentType{type=MCBean, subtype=*}), compName=JMXRegistrationAdvice$AspectBinding, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=jboss.system:type=MCServer, type=(ComponentType{type=MCBean, subtype=MCServer}), compName=jboss.system:type=MCServer, attachment: org.jboss.bootstrap.impl.as.server.JBossASServerImpl
++++++ properties: [buildID, buildOS, buildNumber, startDate, config, buildDate, versionName, buildJVM, version, versionNumber]
+++ ManagedComponent(name=jboss.system:type=ServerConfig, type=(ComponentType{type=MCBean, subtype=ServerConfig}), compName=jboss.system:type=ServerConfig, attachment: org.jboss.bootstrap.impl.as.config.BasicJBossASServerConfig
++++++ properties: [serverHomeDir, serverLogLocation, udpGroup, homeUrl, serverLogDir, serverDataLocation, homeDir, serverLibraryURL, serverDataDir, bindAddress, nativeLibraryLocation, serverName, commonBaseURL, serverHomeURL, bootstrapURL, serverTempDir, serverNativeDir, partitionName, udpPort, commonLibraryURL, serverBaseDir, serverTempLocation, serverConfLocation, bootLibraryLocation, serverBaseURL]
+++ ManagedComponent(name=AspectManagerJMXRegistrar, type=(ComponentType{type=MCBean, subtype=*}), compName=AspectManagerJMXRegistrar, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=JMXCreateDestroyAdvice$AspectBinding, type=(ComponentType{type=MCBean, subtype=*}), compName=JMXCreateDestroyAdvice$AspectBinding, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
ManagedDeployment: file:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/bootstrap/profile.xml
+++ ManagedComponent(name=AttachmentStore, type=(ComponentType{type=MCBean, subtype=*}), compName=AttachmentStore, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=MetaDataStructureModificationChecker$filter#1, type=(ComponentType{type=MCBean, subtype=*}), compName=MetaDataStructureModificationChecker$filter#1, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=DeploymentFilter, type=(ComponentType{type=MCBean, subtype=*}), compName=DeploymentFilter, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ComponentMapperRegistry, type=(ComponentType{type=MCBean, subtype=*}), compName=ComponentMapperRegistry, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ProfileRepositoryFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=ProfileRepositoryFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ProfileFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=ProfileFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=StructureModificationChecker, type=(ComponentType{type=MCBean, subtype=*}), compName=StructureModificationChecker, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ProfileServiceBootstrap, type=(ComponentType{type=MCBean, subtype=*}), compName=ProfileServiceBootstrap, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=BootstrapProfileFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=BootstrapProfileFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=MetaDataStructureModificationChecker, type=(ComponentType{type=MCBean, subtype=*}), compName=MetaDataStructureModificationChecker, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ProfileServicePersistenceDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ProfileServicePersistenceDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ProfileService, type=(ComponentType{type=MCBean, subtype=*}), compName=ProfileService, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=WebVisitorAttributes, type=(ComponentType{type=MCBean, subtype=*}), compName=WebVisitorAttributes, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=DefaultProfileKey, type=(ComponentType{type=MCBean, subtype=*}), compName=DefaultProfileKey, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=DefaultDeploymentRepositoryFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=DefaultDeploymentRepositoryFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ServiceDeploymentComponentMapper, type=(ComponentType{type=MCBean, subtype=*}), compName=ServiceDeploymentComponentMapper, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=SynchAdapter, type=(ComponentType{type=MCBean, subtype=*}), compName=SynchAdapter, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=StructureModCache, type=(ComponentType{type=MCBean, subtype=*}), compName=StructureModCache, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=BasicProfileFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=BasicProfileFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=KernelDeploymentComponentMapper, type=(ComponentType{type=MCBean, subtype=*}), compName=KernelDeploymentComponentMapper, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=PersistenceFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=PersistenceFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=FilteredProfileFactory, type=(ComponentType{type=MCBean, subtype=*}), compName=FilteredProfileFactory, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=profile-classloader:0.0.0, type=(ComponentType{type=MCBean, subtype=*}), compName=profile-classloader:0.0.0, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=AttachmentsSerializer, type=(ComponentType{type=MCBean, subtype=*}), compName=AttachmentsSerializer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=ProfileServiceDeployer, type=(ComponentType{type=MCBean, subtype=*}), compName=ProfileServiceDeployer, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
+++ ManagedComponent(name=profile-classloader:0.0.0$MODULE, type=(ComponentType{type=MCBean, subtype=*}), compName=profile-classloader:0.0.0$MODULE, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [state, properties]
ManagedDeployment: http-127.0.0.1-8080
+++ ManagedComponent(name=jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor, type=(ComponentType{type=MBean, subtype=WebRequestProcessor}), compName=jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor, attachment: null
++++++ properties: [modelerType, bytesReceived, errorCount, bytesSent, processingTime, requestCount, maxTime]
+++ ManagedComponent(name=jboss.web:name=http-127.0.0.1-8080,type=ThreadPool, type=(ComponentType{type=MBean, subtype=WebThreadPool}), compName=jboss.web:name=http-127.0.0.1-8080,type=ThreadPool, attachment: null
++++++ properties: [maxThreads, backlog, currentThreadsBusy, acceptorThreadCount, threadPriority, paused, port, tcpNoDelay, soLinger, modelerType, soTimeout, daemon, running, currentThreadCount, name]
ManagedDeployment: localhost
+++ ManagedComponent(name=jboss.web:host=localhost,type=Host, type=(ComponentType{type=MBean, subtype=WebHost}), compName=jboss.web:host=localhost,type=Host, attachment: null
++++++ properties: [deployOnStartup, valveNames, deployXML, realm, xmlNamespaceAware, xmlValidation, modelerType, valveObjectNames, appBase, autoDeploy, configClass, name, children, aliases, unpackWARs, managedResource]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/bindingservice.beans/
+++ ManagedComponent(name=ServiceBindingManager, type=(ComponentType{type=MCBean, subtype=ServiceBindingManager}), compName=ServiceBindingManagementObject, attachment: org.jboss.services.binding.managed.ServiceBindingManagementObject
++++++ properties: [bindingSets, state, activeBindingSetName, standardBindings, serviceBindings]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/jboss-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ROOT.war/
+++ ManagedComponent(name=ContextMO, type=(ComponentType{type=WAR, subtype=Context}), compName=null, attachment: org.jboss.web.deployers.AbstractWarDeployer$ContextMO
++++++ properties: [contextRoot]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/admin-console.war/
+++ ManagedComponent(name=ContextMO, type=(ComponentType{type=WAR, subtype=Context}), compName=null, attachment: org.jboss.web.deployers.AbstractWarDeployer$ContextMO
++++++ properties: [contextRoot]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/cache-invalidation-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ejb2-container-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ejb2-timer-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ejb3-connectors-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ejb3-container-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ejb3-interceptors-aop.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/ejb3-timerservice-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/hdscanner-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/hsqldb-ds.xml
+++ ManagedComponent(name=DefaultDS, type=(ComponentType{type=DataSource, subtype=LocalTx}), compName=null, attachment: org.jboss.resource.metadata.mcf.LocalDataSourceDeploymentMetaData
++++++ properties: [valid-connection-checker-class-name, validate-on-match, connection-url, url-delimiter, connectionDestroyedCount, local-transaction, jmx-invoker-name, security-domain, max-pool-size, share-prepared-statements, interleaving, statistics-formatter, maxConnectionsInUseCount, set-tx-query-timeout, use-try-lock, type-mapping, connection-definition, idle-timeout-minutes, rar-name, check-valid-connection-sql, connection-properties, connectionCreatedCount, new-connection-sql, background-validation-millis, inUseConnectionCount, jndi-name, metadata, driver-class, min-pool-size, prepared-statement-cache-size, availableConnectionCount, exception-sorter-class-name, track-connection-by-tx, no-tx-separate-pools, use-strict-min, prefill, password, minSize, use-java-context, maxSize, stale-connection-checker-class-name, blocking-timeout-millis, config-property, poolJndiName, isSameRM-override-value, transaction-isolation, background-validation, track-statements, user-name, connectionCount, allocation-retry, query-timeout, url-selector-strategy-class-name, allocation-retry-wait-millis]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/http-invoker.sar/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/http-invoker.sar/invoker.war/
+++ ManagedComponent(name=ContextMO, type=(ComponentType{type=WAR, subtype=Context}), compName=null, attachment: org.jboss.web.deployers.AbstractWarDeployer$ContextMO
++++++ properties: [contextRoot]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jbossweb.sar/
+++ ManagedComponent(name=jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor, type=(ComponentType{type=MBean, subtype=Web}), compName=ConnectorBean-http-${jboss.bind.address}-8080MO, attachment: org.jboss.web.tomcat.service.management.ConnectorBean
++++++ properties: [bytesReceived, errorCount, mbeanNameAsString, bytesSent, state, processingTime, requestCount, maxTime]
+++ ManagedComponent(name=jboss.web:name=http-127.0.0.1-8080,type=ThreadPool, type=(ComponentType{type=MBean, subtype=Web}), compName=ThreadPool-http-${jboss.bind.address}-8080MO, attachment: org.jboss.web.tomcat.service.management.ThreadPool
++++++ properties: [maxThreads, mbeanNameAsString, currentThreadsBusy, state, threadPriority, currentThreadCount]
+++ ManagedComponent(name=jboss.web:host=127.0.0.1,type=Host, type=(ComponentType{type=MBean, subtype=Web}), compName=${jboss.bind.address}-MO, attachment: org.jboss.web.tomcat.service.management.Host
++++++ properties: [valveNames, mbeanNameAsString, state, aliases, unpackWARs]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jbossws.sar/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jbossws.sar/jbossws-management.war/
+++ ManagedComponent(name=ContextMO, type=(ComponentType{type=WAR, subtype=Context}), compName=null, attachment: org.jboss.web.deployers.AbstractWarDeployer$ContextMO
++++++ properties: [contextRoot]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jca-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jmx-console.war/
+++ ManagedComponent(name=ContextMO, type=(ComponentType{type=WAR, subtype=Context}), compName=null, attachment: org.jboss.web.deployers.AbstractWarDeployer$ContextMO
++++++ properties: [contextRoot]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jmx-invoker-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jmx-remoting.sar/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jsr88-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/legacy-invokers-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/mail-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/management/console-mgr.sar/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/management/console-mgr.sar/web-console.war/
+++ ManagedComponent(name=ContextMO, type=(ComponentType{type=WAR, subtype=Context}), compName=null, attachment: org.jboss.web.deployers.AbstractWarDeployer$ContextMO
++++++ properties: [contextRoot]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/connection-factories-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/destinations-service.xml
+++ ManagedComponent(name=/queue/ExpiryQueue, type=(ComponentType{type=JMSDestination, subtype=Queue}), compName=jboss.messaging.destination:name=ExpiryQueue,service=Queue, attachment: org.jboss.jms.server.destination.QueueServiceMO
++++++ properties: [downCacheSize, createdProgrammatically, maxSize, scheduledMessageCount, messageStatistics, securityConfig, consumerCount, JNDIName, messageCount, messageCounterHistoryDayLimit, maxDeliveryAttempts, redeliveryDelay, fullSize, messageCounter, pageSize, deliveringCount, expiryQueue, DLQ, name, clustered, serverPeer]
+++ ManagedComponent(name=/queue/DLQ, type=(ComponentType{type=JMSDestination, subtype=Queue}), compName=jboss.messaging.destination:name=DLQ,service=Queue, attachment: org.jboss.jms.server.destination.QueueServiceMO
++++++ properties: [downCacheSize, createdProgrammatically, maxSize, scheduledMessageCount, messageStatistics, securityConfig, consumerCount, JNDIName, messageCount, messageCounterHistoryDayLimit, maxDeliveryAttempts, redeliveryDelay, fullSize, messageCounter, pageSize, deliveringCount, expiryQueue, DLQ, name, clustered, serverPeer]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/hsqldb-persistence-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/jms-ds.xml
+++ ManagedComponent(name=JmsXA, type=(ComponentType{type=ConnectionFactory, subtype=Tx}), compName=null, attachment: org.jboss.resource.metadata.mcf.TxConnectionFactoryDeploymentMetaData
++++++ properties: [jndi-name, validate-on-match, metadata, connectionDestroyedCount, local-transaction, min-pool-size, availableConnectionCount, jmx-invoker-name, security-domain, max-pool-size, no-tx-separate-pools, use-strict-min, interleaving, statistics-formatter, track-connection-by-tx, prefill, minSize, use-java-context, maxSize, xa-transaction, maxConnectionsInUseCount, blocking-timeout-millis, type-mapping, config-property, connection-definition, idle-timeout-minutes, poolJndiName, isSameRM-override-value, background-validation, rar-name, connectionCount, connectionCreatedCount, xa-resource-timeout, allocation-retry, background-validation-millis, inUseConnectionCount, allocation-retry-wait-millis]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/legacy-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/messaging-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/messaging-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/messaging/remoting-bisocket-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/monitoring-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/profileservice-jboss-beans.xml
+++ ManagedComponent(name=ManagementView, type=(ComponentType{type=MCBean, subtype=*}), compName=ManagementView, attachment: org.jboss.profileservice.management.ManagementViewImpl
++++++ properties: [state]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/profileservice-secured.jar/
+++ ManagedComponent(name=SecureProfileService-metrics-instance, type=(ComponentType{type=EJB3, subtype=SLSB}), compName=SecureProfileService-metrics-instance, attachment: org.jboss.ejb3.metrics.deployer.BasicStatelessSessionInstanceMetrics
++++++ properties: [removeCount, currentSize, maxSize, createCount, availableCount]
+++ ManagedComponent(name=SecureDeploymentManager-metrics-instance, type=(ComponentType{type=EJB3, subtype=SLSB}), compName=SecureDeploymentManager-metrics-instance, attachment: org.jboss.ejb3.metrics.deployer.BasicStatelessSessionInstanceMetrics
++++++ properties: [removeCount, currentSize, maxSize, createCount, availableCount]
+++ ManagedComponent(name=SecureManagementView-metrics-instance, type=(ComponentType{type=EJB3, subtype=SLSB}), compName=SecureManagementView-metrics-instance, attachment: org.jboss.ejb3.metrics.deployer.BasicStatelessSessionInstanceMetrics
++++++ properties: [removeCount, currentSize, maxSize, createCount, availableCount]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/properties-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/remoting-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/schedule-manager-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/scheduler-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/security/security-jboss-beans.xml
+++ ManagedComponent(name=JNDIBasedSecurityRegistration, type=(ComponentType{type=MCBean, subtype=Security}), compName=JNDIBasedSecurityRegistration, attachment: org.jboss.beans.metadata.plugins.AbstractBeanMetaData
++++++ properties: [start, demands, installs, classLoader, properties, uninstalls, related, destroy, annotations, accessMode, errorHandlingMode, constructor, create, aliasMetaData, autowireType, installCallbacks, name, beans, supplies, uninstallCallbacks, mode, bean, depends, classShortName, stop, abstract, description, underlyingValue, state, autowireCandidate, parent, children, aliases]
+++ ManagedComponent(name=XMLLoginConfig, type=(ComponentType{type=MCBean, subtype=Security}), compName=XMLLoginConfig, attachment: org.jboss.security.auth.login.XMLLoginConfig
++++++ properties: [validateDTD, state, configURL]
+++ ManagedComponent(name=JBossSecuritySubjectFactory, type=(ComponentType{type=MCBean, subtype=Security}), compName=JBossSecuritySubjectFactory, attachment: org.jboss.security.integration.JBossSecuritySubjectFactory
++++++ properties: [state, securityManagement]
+++ ManagedComponent(name=SecurityConfig, type=(ComponentType{type=MCBean, subtype=Security}), compName=SecurityConfig, attachment: org.jboss.security.plugins.SecurityConfig
++++++ properties: [loginConfig, mbeanServer, state, defaultLoginConfig]
+++ ManagedComponent(name=JNDIBasedSecurityManagement, type=(ComponentType{type=MCBean, subtype=Security}), compName=JNDIBasedSecurityManagement, attachment: org.jboss.security.integration.JNDIBasedSecurityManagement
++++++ properties: [identityTrustMgrClass, authorizationMgrClass, authenticationMgrClass, state, auditMgrClass, mappingMgrClass]
+++ ManagedComponent(name=JNDIContextEstablishment, type=(ComponentType{type=MCBean, subtype=Security}), compName=JBossSecurityJNDIContextEstablishment, attachment: org.jboss.security.integration.JNDIContextEstablishment
++++++ properties: [baseContext, factoryName, state]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/security/security-policies-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/sqlexception-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/transaction-jboss-beans.xml
+++ ManagedComponent(name=TransactionManager, type=(ComponentType{type=MCBean, subtype=JTA}), compName=TransactionManager, attachment: com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean
++++++ properties: [transactionManager, recoveryInetAddress, runInVMRecoveryManager, commitCount, transactionStatusManagerInetAddress, applicationRollbackCount, statisticsEnabled, rollbackCount, transactionStatusManagerPort, transactionTimeout, heuristicCount, transactionSynchronizationRegistry, objectStoreDir, runningTransactionCount, nestedTransactonCount, recoveryPort, userTransaction, resourceRollbackCount, XATerminator, socketProcessIdPort, transactionCount, propagateFullContext, state, timedoutCount]
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/transaction-service.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/uuid-key-generator.sar/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/vfs-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/xnio-provider.jar/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/alias-deployers-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/bsh.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/clustering-deployer-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/dependency-deployers-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/directory-deployer-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/ear-deployer-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/ejb-deployer-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/ejb3.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/hibernate-deployer-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-aop-jboss5.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-jca.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-threads.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossweb.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jsr77-deployers-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/logbridge-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/messaging-definitions-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/metadata-deployer-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/seam.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/security-deployer-jboss-beans.xml
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/webbeans.deployer/
ManagedDeployment: vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/xnio.deployer/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/conf/bindingservice.beans/jboss-bindingservice.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jboss-local-jdbc.rar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jboss-local-jdbc.rar/jboss-local-jdbc.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jboss-xa-jdbc.rar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jboss-xa-jdbc.rar/jboss-xa-jdbc.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jms-ra.rar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jms-ra.rar/jms-ra.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/jmx-remoting.sar/jbossas-jmx-remoting.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/mail-ra.rar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/mail-ra.rar/mail-ra.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/management/console-mgr.sar/console-mgr-classes.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/management/console-mgr.sar/jcommon.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/management/console-mgr.sar/jfreechart.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/quartz-ra.rar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/quartz-ra.rar/quartz-ra.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/xnio-provider.jar/xnio-nio.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/bsh.deployer/bsh-deployer.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/ejb3.deployer/jboss-ejb3-deployer.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/ejb3.deployer/jboss-ejb3-iiop.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-aop-jboss5.deployer/jboss-aop-aspects.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-aop-jboss5.deployer/jboss-aspect-library.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-aop-jboss5.deployer/jrockit-pluggable-instrumentor.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-aop-jboss5.deployer/pluggable-instrumentor.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-ejb3-endpoint-deployer.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-ejb3-metrics-deployer.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-jca.deployer/jboss-jca-deployer.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jboss-threads.deployer/jboss-threads-metadata.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/FastInfoset.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/jboss-jaxb-intros.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/jbossws-common.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/jbossws-framework.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/jbossws-jboss50.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/jbossws-native-core.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/jettison.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/policy.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/wsdl4j.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/jbossws.deployer/xmlsec.jar/
ManagedDeployment: vfszip:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deployers/xnio.deployer/xnio-metadata.jar/


> ManagementView.getDeployment should always at least return a structural view of a deployment
> --------------------------------------------------------------------------------------------
>
>                 Key: JBAS-5452
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5452
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services, ProfileService
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently the ManagementView.getDeployment(String name, DeploymentPhase phase) api requires a deployment to have @ManagementDeployment/@ManagementObject/@ManagementComponent annotations to build any type of view of the deployment. There should be a basic structure view returned in the absence of any @ManagementObject/@ManagementComponent info. It would just be the structure view with a ManagedDeployment graph that mirrors the StructureMetaData.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Jun 10 03:11:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Wed, 10 Jun 2009 03:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Work started: (JBID-68) identity
	component in JBoss5.
In-Reply-To: <1982607.1237796302346.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25607303.1244617916538.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on JBID-68 started by Jeff Yu.

> identity component in JBoss5.
> -----------------------------
>
>                 Key: JBID-68
>                 URL: https://jira.jboss.org/jira/browse/JBID-68
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> quote from Tom Baeyenes:
> What we need is an automated installation to install the identity component in a naked JBoss5, That automated installation should cover at least cover proper configuration of the identity component to oracle, mysql, hsqldb and postgresql. Also we'll need automatic way of generating or obtaining the DDL scripts to create and drop the DB tables.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:49:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Wed, 10 Jun 2009 03:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-79) Write a JBossAS5
 deployer for idm config file.
In-Reply-To: <30830990.1239614137512.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21071356.1244620196688.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Yu resolved JBID-79.
-------------------------

    Resolution: Done


> Write a JBossAS5 deployer for idm config file.
> ----------------------------------------------
>
>                 Key: JBID-79
>                 URL: https://jira.jboss.org/jira/browse/JBID-79
>             Project: JBoss Identity
>          Issue Type: Task
>          Components: IDM
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> Write a JBossAS5 deployer for idm config file.
> Like, use the -idm.xml (or properties file) as a suffix to boostrap the realm.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:43:07 2009
From: jira-events at lists.jboss.org (Krashan Brahmanjara (JIRA))
Date: Wed, 10 Jun 2009 03:43:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1846) CLONE -Injected
 SessionContext became invalid after passivation
Message-ID: <27788759.1244619787592.JavaMail.jira@cloud.prod.atl2.jboss.com>

CLONE -Injected SessionContext became invalid after passivation
---------------------------------------------------------------

                 Key: EJBTHREE-1846
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1846
             Project: EJB 3.0
          Issue Type: Bug
          Components: injection
    Affects Versions: AS 4.2.2.GA
            Reporter: Krashan Brahmanjara
            Assignee: Andrew Lee Rubinger


I have SFSB with SessionContext injected as:

@Resource
private SessionContext ctx;

Some of my SFSB's methods use ctx.getBusinessObject(). After passivation and activation of bean ctx.getBusinessObject() produces NPE.
While debugging I discover that ctx is instance of org.jboss.ejb3.BaseSessionContext. In it's writeExternal() / readExternal() it loose baseContext, which is needed for getBusinessObject() invocation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:49:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Wed, 10 Jun 2009 03:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-68) identity component in
	JBoss5.
In-Reply-To: <1982607.1237796302346.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4638529.1244620196518.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Yu resolved JBID-68.
-------------------------

    Resolution: Done


> identity component in JBoss5.
> -----------------------------
>
>                 Key: JBID-68
>                 URL: https://jira.jboss.org/jira/browse/JBID-68
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> quote from Tom Baeyenes:
> What we need is an automated installation to install the identity component in a naked JBoss5, That automated installation should cover at least cover proper configuration of the identity component to oracle, mysql, hsqldb and postgresql. Also we'll need automatic way of generating or obtaining the DDL scripts to create and drop the DB tables.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:44:56 2009
From: jira-events at lists.jboss.org (Krashan Brahmanjara (JIRA))
Date: Wed, 10 Jun 2009 03:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1846) CLONE -Injected
 SessionContext became invalid after passivation
In-Reply-To: <27788759.1244619787592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20929215.1244619896505.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Krashan Brahmanjara updated EJBTHREE-1846:
------------------------------------------

          Environment: JBoss AS 5.1.0DR
          Component/s:     (was: injection)
    Affects Version/s: AS 5.0.0.CR1
                           (was: AS 4.2.2.GA)


> CLONE -Injected SessionContext became invalid after passivation
> ---------------------------------------------------------------
>
>                 Key: EJBTHREE-1846
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1846
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 5.0.0.CR1
>         Environment: JBoss AS 5.1.0DR
>            Reporter: Krashan Brahmanjara
>            Assignee: Andrew Lee Rubinger
>
> I have SFSB with SessionContext injected as:
> @Resource
> private SessionContext ctx;
> Some of my SFSB's methods use ctx.getBusinessObject(). After passivation and activation of bean ctx.getBusinessObject() produces NPE.
> While debugging I discover that ctx is instance of org.jboss.ejb3.BaseSessionContext. In it's writeExternal() / readExternal() it loose baseContext, which is needed for getBusinessObject() invocation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:59:56 2009
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Wed, 10 Jun 2009 03:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-99) Unique attributes
In-Reply-To: <3795253.1242040366371.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1213823.1244620796633.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Boleslaw Dawidowicz resolved JBID-99.
-------------------------------------

    Resolution: Done


> Unique attributes
> -----------------
>
>                 Key: JBID-99
>                 URL: https://jira.jboss.org/jira/browse/JBID-99
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Boleslaw Dawidowicz
>            Assignee: Boleslaw Dawidowicz
>             Fix For: idm-1.0.0.Beta2
>
>
> Add possibility to mark attribute as unique. This means that given the value is unique in scope of IdentityObjectType (for Users or within given GroupType). There should be an API to query single User or Group based on such attribute value. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:39:56 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-293) Enhance the graphical
	view
In-Reply-To: <5322076.1231385704002.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14270755.1244626796685.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-293:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)


indeed post ga is better.
i leave this issue in 4.0.x, but i think that if you address some of these that you should create individual issues for them

> Enhance the graphical view
> --------------------------
>
>                 Key: GPD-293
>                 URL: https://jira.jboss.org/jira/browse/GPD-293
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> - (optional) labels for transitions, events and gateways
> - labels should be movable
> - preferences pages (enable/disable nodes)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:41:57 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:41:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-226) Define a repeatable
 build for
 these plugins to be exported as a feature and as a rich client application
In-Reply-To: <23044378.1216376452176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15864680.1244626917069.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/GPD-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471375#action_12471375 ] 

Tom Baeyens commented on GPD-226:
---------------------------------

Yes, RCP should be post GA.  So I'll remove it from the title.

> Define a repeatable build for these plugins to be exported as a feature and as a rich client application
> --------------------------------------------------------------------------------------------------------
>
>                 Key: GPD-226
>                 URL: https://jira.jboss.org/jira/browse/GPD-226
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:14:57 2009
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Wed, 10 Jun 2009 05:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-73) Add a
 DisassociateGroups(User user) API in the relationshipManager
In-Reply-To: <13575914.1238569174507.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10308128.1244625297120.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Boleslaw Dawidowicz resolved JBID-73.
-------------------------------------

    Resolution: Done


> Add a DisassociateGroups(User user) API in the relationshipManager
> ------------------------------------------------------------------
>
>                 Key: JBID-73
>                 URL: https://jira.jboss.org/jira/browse/JBID-73
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM, SOARequirements
>            Reporter: Jeff Yu
>            Assignee: Boleslaw Dawidowicz
>             Fix For: idm-1.0.0.Beta1
>
>
> This is the use case from SOA-Repository Identity module.
> I had Users and Groups Object, now in the UI layer, administrator update the user's groups, in the implementation, it would delete all the existing association with groups, and then created association with the new collection of group.
> So, I want to have APIs like:
> disassociateGroups(User user): It remove all of the group association with the provided User.
> disassociateGroups(String userId): It remove all of the group association with the provided userId.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:39:56 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-292) Enhance Node
	Pluggability
In-Reply-To: <8457015.1231385523992.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27692921.1244626796516.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-292:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)


> Enhance Node Pluggability
> -------------------------
>
>                 Key: GPD-292
>                 URL: https://jira.jboss.org/jira/browse/GPD-292
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> It should be possible to add nodes by adding a jar file (containing a configuration and possibly some java classes and icons) in a well-defined location.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:23:57 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 10 Jun 2009 05:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1846) CLONE -Injected
 SessionContext became invalid after passivation
In-Reply-To: <27788759.1244619787592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28252441.1244625837172.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf reassigned EJBTHREE-1846:
---------------------------------------

    Assignee: Carlo de Wolf  (was: Andrew Lee Rubinger)


> CLONE -Injected SessionContext became invalid after passivation
> ---------------------------------------------------------------
>
>                 Key: EJBTHREE-1846
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1846
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 5.0.0.CR1
>         Environment: JBoss AS 5.1.0DR
>            Reporter: Krashan Brahmanjara
>            Assignee: Carlo de Wolf
>
> I have SFSB with SessionContext injected as:
> @Resource
> private SessionContext ctx;
> Some of my SFSB's methods use ctx.getBusinessObject(). After passivation and activation of bean ctx.getBusinessObject() produces NPE.
> While debugging I discover that ctx is instance of org.jboss.ejb3.BaseSessionContext. In it's writeExternal() / readExternal() it loose baseContext, which is needed for getBusinessObject() invocation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:45:56 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-285) Support form
 generation for the new GWT console
In-Reply-To: <1779469.1231384383996.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15372630.1244627156477.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-285:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)


form tech is pluggable.  let's first build up some experience with the current forms tech to make sure that we don't switch forms tech after you've added forms generation capabilities.

> Support form generation for the new GWT console
> -----------------------------------------------
>
>                 Key: GPD-285
>                 URL: https://jira.jboss.org/jira/browse/GPD-285
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.x
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Ideally we should be able to produce a file that respects a 'standard' for which there already exist graphical gui builders.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:47:57 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:47:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-337) image clipping
In-Reply-To: <22840615.1242894476675.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19403080.1244627277081.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-337:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)


not important.  and from what i understood, this requires research, which is not worthed.

> image clipping
> --------------
>
>                 Key: GPD-337
>                 URL: https://jira.jboss.org/jira/browse/GPD-337
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> the generated images are too large.  clipping them would be nice to have.  
> watch out with clipping the top left corner (i assume that is coordinates 0,0).  if you clip that while saving the image, then the coordinates in the process, used by the console might be affected.  
> while clipping the bottom right  corner should be possible without problem for the console.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 07:11:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 10 Jun 2009 07:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1641) Stopping
 the bridge service doesn't stop the failure handler
In-Reply-To: <31429260.1244473017316.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23335902.1244632316986.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471397#action_12471397 ] 

Howard Gao commented on JBMESSAGING-1641:
-----------------------------------------

The simplest solution is to add a boolean flag forceStop for the failure handler threads. In bridge stop(), we set it to true. In the retry loop of the failure handler, we check the flag after each retry. If the flag is true, stop retry and returns. The thread will then stop.


> Stopping the bridge service doesn't stop the failure handler
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1641
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1641
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> when bridge is stopped via the JMX, the stop() action doesn't stop the failure handler, which will keep trying to reconnect even after bridge service has been stopped.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:46:56 2009
From: jira-events at lists.jboss.org (Krashan Brahmanjara (JIRA))
Date: Wed, 10 Jun 2009 03:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1846) CLONE -Injected
 SessionContext became invalid after passivation
In-Reply-To: <27788759.1244619787592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21341234.1244620016618.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471348#action_12471348 ] 

Krashan Brahmanjara commented on EJBTHREE-1846:
-----------------------------------------------

That problem still exist.  Code below throws NPE at ctx.getBusinessObject. 

 private @Resource SessionContext ctx;
 TestLocal testBean;

 public TestBean() {
    super();
    testBean = ctx.getBusinessObject(TestLocal.class);
  }

> CLONE -Injected SessionContext became invalid after passivation
> ---------------------------------------------------------------
>
>                 Key: EJBTHREE-1846
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1846
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 5.0.0.CR1
>         Environment: JBoss AS 5.1.0DR
>            Reporter: Krashan Brahmanjara
>            Assignee: Andrew Lee Rubinger
>
> I have SFSB with SessionContext injected as:
> @Resource
> private SessionContext ctx;
> Some of my SFSB's methods use ctx.getBusinessObject(). After passivation and activation of bean ctx.getBusinessObject() produces NPE.
> While debugging I discover that ctx is instance of org.jboss.ejb3.BaseSessionContext. In it's writeExternal() / readExternal() it loose baseContext, which is needed for getBusinessObject() invocation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 06:50:57 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 10 Jun 2009 06:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-204) Validation errors
 in jboss_5_1.xsd (missing webservice-descriptionType)
In-Reply-To: <523654.1244473976786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24728855.1244631057062.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471391#action_12471391 ] 

Alexey Loubyansky commented on JBMETA-204:
------------------------------------------

5_1 schemas are considered production ready. The error posted means schema binding was not resolved as it should have been, i.e. instead of using schema binding based on Java JAXB/JBossXB annotations, the schema binding was built by parsing XSD which won't work. Perhaps this is related to your attempts to modify schemaLocations and the resolution process.
Let's use user forums to continue since so far it's only a discussion. (Add the forum thread URL to this issue so I don't miss it) Thanks.

> Validation errors in jboss_5_1.xsd (missing webservice-descriptionType)
> -----------------------------------------------------------------------
>
>                 Key: JBMETA-204
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-204
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Zachary Bedell
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>
> An additional validation issue with current trunk jboss_5_1.xsd.  The webservicesType complex type references type jboss:webservice-descriptionType which is missing.  Copying the type from the jboss_5_0.xsd (which appears directly the webservicesType object around line 1223) resolves the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 06:12:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 10 Jun 2009 06:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1846) CLONE -Injected
 SessionContext became invalid after passivation
In-Reply-To: <27788759.1244619787592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14092312.1244628776534.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved EJBTHREE-1846.
-------------------------------------

    Resolution: Cannot Reproduce Bug


StatefulSessionContextImpl is the implementation of SessionContext that is injected into the bean. When getBusinessObject is called after activation it'll reinstantiate a delegate in getDelegate referencing the container.

BaseSessionContext is a class from AS 4 and no longer in use. If you need help on AS 4 post in the forums or file a support case.

> CLONE -Injected SessionContext became invalid after passivation
> ---------------------------------------------------------------
>
>                 Key: EJBTHREE-1846
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1846
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 5.0.0.CR1
>         Environment: JBoss AS 5.1.0DR
>            Reporter: Krashan Brahmanjara
>            Assignee: Carlo de Wolf
>
> I have SFSB with SessionContext injected as:
> @Resource
> private SessionContext ctx;
> Some of my SFSB's methods use ctx.getBusinessObject(). After passivation and activation of bean ctx.getBusinessObject() produces NPE.
> While debugging I discover that ctx is instance of org.jboss.ejb3.BaseSessionContext. In it's writeExternal() / readExternal() it loose baseContext, which is needed for getBusinessObject() invocation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:30:56 2009
From: jira-events at lists.jboss.org (Krashan Brahmanjara (JIRA))
Date: Wed, 10 Jun 2009 03:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6122) Regression: Unable
 to deploy self referencing EJB3 session bean
In-Reply-To: <4298875.1224591920917.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3146678.1244619056530.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471345#action_12471345 ] 

Krashan Brahmanjara commented on JBAS-6122:
-------------------------------------------

>Although this should work in AS 5.0, you should use getBusinessObject to obtain a self-reference

It also doesn't work. I got nullPointerExceptions. Any resolution?

class
public class TestBean implements TestLocal, TestRemote {
 @Resource
  SessionContext ctx;
  // @EJB
  Test2Local test2Bean;
  
  public TestBean() {
    super();
    test2Bean = ctx.getBusinessObject(TestLocal.class);
  }
}


> Regression: Unable to deploy self referencing EJB3 session bean
> ---------------------------------------------------------------
>
>                 Key: JBAS-6122
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6122
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: Fedora Linux 9, Sun JDK 1.6.0_06
>            Reporter: Radu Radutiu
>            Assignee: Carlo de Wolf
>
> The following stateless EJB which has a self reference using @EJBs() annotation deploys fine on jboss-4.2.3 but fails to deploy on jboss-5.0.0CR2. 
> package test;
> import javax.ejb.*;
> @EJBs({@EJB(name="TestSessionBean/local",beanInterface=LocalTestSession.class,beanName="TestSessionBean")})
> @Stateless(name="TestSessionBean")
> public class TestSessionBean implements LocalTestSession {
> 	public String test() {
> 		try {
> 	        InitialContext ic = new InitialContext();
> 	        LocalTestSession lc = (LocalTestSession) ic.lookup("java:comp/env/TestSessionBean/local");
> 	        System.out.println(lc.test1());
>         } catch (NamingException e) {
> 	        e.printStackTrace();
>         }
> 		return "test";
> 	}
> 	
> 	public String test1() {
> 		return "test1";
> 	}
> 	
> }
> When deploying the jar on jboss-5.0.0CR2 I get the following error:
> 09:57:19,227 WARN  [HDScanner] Failed to process changes
> org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE
>  PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> jboss.j2ee:ear=test.jar,jar=test.jar,name=TestSessionBean,service=EJB3
>  -> <UNKNOWN jboss.j2ee:ear=test.jar,jar=test.jar,name=TestSessionBean,service=EJB3>{Described:** UNRESOLVED Demands 'jndi:TestSessionBean/local-test.LocalTestSession' **}
> *** CONTEXTS IN ERROR: Name -> Error
> <UNKNOWN jboss.j2ee:ear=test.jar,jar=test.jar,name=TestSessionBean,service=EJB3> -> ** UNRESOLVED Demands 'jndi:TestSessionBean/local-test.LocalTestSession' **

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 07:50:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 10 Jun 2009 07:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMDR-56)
 AnnotatedElementMetadataLoader can
 be improved to handle DeclaredMethodSignature better
Message-ID: <4694138.1244634656561.JavaMail.jira@cloud.prod.atl2.jboss.com>

AnnotatedElementMetadataLoader can be improved to handle DeclaredMethodSignature better
---------------------------------------------------------------------------------------

                 Key: JBMDR-56
                 URL: https://jira.jboss.org/jira/browse/JBMDR-56
             Project: JBoss MetaData Repository
          Issue Type: Task
            Reporter: jaikiran pai
            Assignee: jaikiran pai


Currently the AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval for a DeclaredMethodSignature calls the findMethod which results in first getting all methods of the class and then iterating over them to find the right one. This can be improved to instead call the getDeclaredMethod on the class since the DeclaredMethodSignature has the information about which class declares the method.

Please see the referenced forum thread for details.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 03:54:08 2009
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Wed, 10 Jun 2009 03:54:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-106) Javadoc cleanup and
	update
In-Reply-To: <9413562.1242125158753.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11410925.1244620448531.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Boleslaw Dawidowicz resolved JBID-106.
--------------------------------------

    Resolution: Done


> Javadoc cleanup and update
> --------------------------
>
>                 Key: JBID-106
>                 URL: https://jira.jboss.org/jira/browse/JBID-106
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Boleslaw Dawidowicz
>            Assignee: Boleslaw Dawidowicz
>             Fix For: idm-1.0.0.Beta1
>
>
> Javadoc is outdated or missing in many places. Need to review all API/SPI interfaces and update it where needed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 07:50:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 10 Jun 2009 07:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMDR-56)
 AnnotatedElementMetadataLoader can
 be improved to handle DeclaredMethodSignature better
In-Reply-To: <4694138.1244634656561.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23206481.1244634657017.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMDR-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated JBMDR-56:
------------------------------

          Component/s: Loader
    Affects Version/s: JBossMDR-2.0.1.GA


> AnnotatedElementMetadataLoader can be improved to handle DeclaredMethodSignature better
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMDR-56
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-56
>             Project: JBoss MetaData Repository
>          Issue Type: Task
>          Components: Loader
>    Affects Versions: JBossMDR-2.0.1.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> Currently the AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval for a DeclaredMethodSignature calls the findMethod which results in first getting all methods of the class and then iterating over them to find the right one. This can be improved to instead call the getDeclaredMethod on the class since the DeclaredMethodSignature has the information about which class declares the method.
> Please see the referenced forum thread for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:37:56 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-284) Create an RCP version
	of the GPD
In-Reply-To: <23528169.1231384204004.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13504324.1244626676841.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-284:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)
         Priority: Optional  (was: Major)


i agree.  post ga is better

> Create an RCP version of the GPD
> --------------------------------
>
>                 Key: GPD-284
>                 URL: https://jira.jboss.org/jira/browse/GPD-284
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>            Priority: Optional
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> Part of it is already done. The remaining chunk of work is making sure the build produces the artifacts for the different target platforms and including/enabling some standard actions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 07:20:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 10 Jun 2009 07:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1629) do not
 hard-code management cluster admin user
In-Reply-To: <18532704.1242639846429.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9966451.1244632856683.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1629.
------------------------------------

    Resolution: Done


fixed in the trunk (see changelog)

> do not hard-code management cluster admin user
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1629
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1629
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>
> management cluster admin user is hard-coded in SecurityStoreImpl and we bypass security check for it.
> instead, the user should be configurable (like the management cluster password) and a regular
> user (with "manage" permission) should be created instead.
> From SecurityStoreImpl point of view, this will remove special case to handle this cluster admin user.
> Warning about not changing the default cluster credentials will have to be moved from the SecurityStoreImpl
> to either FileConfiguration (when reading the value from the conf) or ManagementServiceImpl

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:44:07 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:44:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-226) Define a repeatable
 build for these plugins to be exported as a feature
In-Reply-To: <23044378.1216376452176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12064034.1244627047667.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-226:
----------------------------

    Summary: Define a repeatable build for these plugins to be exported as a feature  (was: Define a repeatable build for these plugins to be exported as a feature and as a rich client application)


> Define a repeatable build for these plugins to be exported as a feature
> -----------------------------------------------------------------------
>
>                 Key: GPD-226
>                 URL: https://jira.jboss.org/jira/browse/GPD-226
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 08:11:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 10 Jun 2009 08:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1645)
	Multi-threaded replication
Message-ID: <19987581.1244635916851.JavaMail.jira@cloud.prod.atl2.jboss.com>

Multi-threaded replication
--------------------------

                 Key: JBMESSAGING-1645
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1645
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
            Assignee: Tim Fox
             Fix For: 2.0.0.GA


Currently replication between live and backup node is done on a single thread. The operation is replicated, executed on backup, and when the result is returned to live, it is executed on live before the result is returned to the client (if applicable). This ensures the same ordering of state changes on live and backup but effectively makes all operation single threaded, thus reducing throughput in a clustered set-up.

Instead we should implement multi-threaded replication. If replicated operations are being executed concurrently on backup it is more tricky to ensure that state changes on any object occur in the  same order as on live but it is possible.

This is how we can do it.

For the following types of objects it is important that their state changes occur in the same order on live and backup

1) Sessions (S)
2) Queues (Q)
3) Post offices. (P)

Operations that occur on the live node are either

a) Initiated externally - e.g. an operation like send message or acknowledge coming from a client

b) Initiated internally - e.g. an asynchronous delivery, a depage, or an asynchronous message expiry from the reaper

As any of these operations are being executed they may affect the state of one or more stateful objects, e.g. a send operation might affect the state of S1, Q1, Q2, S2, and S3 (as a sent message is routed to Q1 and Q2 and immediately delivered to S2 and S3).

When the operation is replicated to the backup we must ensure that the state changes on any affected stateful objects must occur in the same order as they did on live.

To do this as the operation is executed and the state changes occur, each stateful object is locked in turn, and a sequence number is obtained from the stateful object which tells us we're the nth stateful operation on that object.

So a send operation might end up with a set of state sequences numbers:

S1(12), Q1(102), Q2(32), S2 (74), S3 (1038)

Which tells us the operation cause the 12th state change on object S1, followed by the 102nd state change on object Q1 etc.

The list of sequence numbers can be stored in a thread local as the operation is executed on live.

When the operation is executed on live we delay sending back any data to the client until we have replicate the operation to the backup and got a response that the replication has been processed.

To ensure the state changes occur in the same order on backup, when we replicate the operation we also replicate the list state sequence numbers. When the operation is executed on the backup we attempt to obtain the locks on the stateful objects.

Say we try to get the lock on object Q1, but the current sequence number of the object Q1 on the backup is 100, the attempt to get the lock will block until the 101st state change is executed since we require that operation is the 102nd state change.

By using such a technique we can ensure that state changes are obtained in the same order on live and backup but are not limited to a single thread.

In many cases the objects will be in the expected or similar sequence numbers so the replications can occur in parallel.

In case of failure of the live node, operations may block indefinitely on the backup waiting for replications to arrive for missing state changes.

For this we can timeout on the lock and reverse state changes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 07:46:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 10 Jun 2009 07:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1603) Rename
 resource MBeans and controls
In-Reply-To: <16977292.1240410748899.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11174723.1244634416518.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1603:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Rename resource MBeans and controls
> -----------------------------------
>
>                 Key: JBMESSAGING-1603
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1603
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0.GA
>
>
> JBM resources are managed either using JMX or JBM Core connections.
> The interfaces follow JMX standard (ending with MBean) even when JBM is not managed through JMX.
> We should rename the management interface XXXMBean to XXXControl and their implementation XXXControl to XXXControlImpl
> (e.g. the resource to manage a queue will have a QueueControl interface and a QueueControlImpl implementation)
> This will continue to work with JMX since we use the StandardMBean to create the MBean registered in the MBeanServer

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 08:23:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 10 Jun 2009 08:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1504) Full Journal
	Compactation
In-Reply-To: <33137475.1234453664451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12065666.1244636636483.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1504:
---------------------------------

               Issue Type: Task  (was: Feature Request)
    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156771
              Description: 
Let me describe how I think the compacting should work.

Let's say we have a set of files in the journal:

F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10

min files is set to 10

The current file is F6 and F7, F8, F9, F10 are unused files waiting to be used

F0, F1, F2, F3, F4, F5 are files full of data and not open any more, however, data about their contents are stored in memory.

We need a compacting thread that intermittently (say every 30 seconds) scans the set of journal files in memory.

It scans F0... F5, and when it has completed that scan, it can decide which records are no longer needed in each file.

A record is no longer needed in a file if it has already been deleted in any file F0.. F5.

Once the scanner thread has computed which records are needed and which are not, it can compute a percentage of which records in total are dead space.

E.g. the scanner might compute that 72% of the data in files F0.. .F5 are dead space.

We then have a parameter that the user can configure compactorDeadSpaceThresholdPercentage, e.g. this might have a default of 75%.

If the amount of dead space computed by the scanner >= compactorDeadSpaceThresholdPercentage, then the scanner will compact those files.

The actual compacting approach goes as follows:

The scanner knows how many new files it will need for the compacted records, let's say it needs two new files - it can get these from the unused files (e.g. F7, F8, F9 or F10) if they are available.

It then opens the old files F0..F5 loads the wanted records into memory in blocks and copies them to the new files.

When this process is finished it will end up with, say, two new files containing the compacted records.

We can then save a marker file (empty in the journal directory) which says we are starting the rename.

The old files F0..F5 then need to be renamed so they are no longer used by the journal (but can be recovered in case of a crash).

Then the two new files need to be renamed so they will be picked up by the journal.

When that process completes the marker file can be deleted.

If the server crashes after renaming the old files but before renaming the new files, then the marker file will still exist in the journal. The journal can detect this on startup, and finish the process.

This ensures the journal will still startup after such a crash.

Also the JournalFile objects also need to be updated in memory when the compact is complete.
                 Priority: Critical  (was: Major)


> Full Journal Compactation
> -------------------------
>
>                 Key: JBMESSAGING-1504
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1504
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Let me describe how I think the compacting should work.
> Let's say we have a set of files in the journal:
> F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10
> min files is set to 10
> The current file is F6 and F7, F8, F9, F10 are unused files waiting to be used
> F0, F1, F2, F3, F4, F5 are files full of data and not open any more, however, data about their contents are stored in memory.
> We need a compacting thread that intermittently (say every 30 seconds) scans the set of journal files in memory.
> It scans F0... F5, and when it has completed that scan, it can decide which records are no longer needed in each file.
> A record is no longer needed in a file if it has already been deleted in any file F0.. F5.
> Once the scanner thread has computed which records are needed and which are not, it can compute a percentage of which records in total are dead space.
> E.g. the scanner might compute that 72% of the data in files F0.. .F5 are dead space.
> We then have a parameter that the user can configure compactorDeadSpaceThresholdPercentage, e.g. this might have a default of 75%.
> If the amount of dead space computed by the scanner >= compactorDeadSpaceThresholdPercentage, then the scanner will compact those files.
> The actual compacting approach goes as follows:
> The scanner knows how many new files it will need for the compacted records, let's say it needs two new files - it can get these from the unused files (e.g. F7, F8, F9 or F10) if they are available.
> It then opens the old files F0..F5 loads the wanted records into memory in blocks and copies them to the new files.
> When this process is finished it will end up with, say, two new files containing the compacted records.
> We can then save a marker file (empty in the journal directory) which says we are starting the rename.
> The old files F0..F5 then need to be renamed so they are no longer used by the journal (but can be recovered in case of a crash).
> Then the two new files need to be renamed so they will be picked up by the journal.
> When that process completes the marker file can be deleted.
> If the server crashes after renaming the old files but before renaming the new files, then the marker file will still exist in the journal. The journal can detect this on startup, and finish the process.
> This ensures the journal will still startup after such a crash.
> Also the JournalFile objects also need to be updated in memory when the compact is complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:41:56 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-306) Self Referencing
	Connections
In-Reply-To: <6129383.1237558244506.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8601015.1244626916869.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/GPD-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471374#action_12471374 ] 

Tom Baeyens commented on GPD-306:
---------------------------------

how are users suppose to do this now ?  can that serve as a workaround ?

> Self Referencing Connections
> ----------------------------
>
>                 Key: GPD-306
>                 URL: https://jira.jboss.org/jira/browse/GPD-306
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>
> There should be a convenient way to create connections that reference the same node as source and target

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 05:44:07 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 05:44:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-226) Define a repeatable
 build for these plugins to be exported as a feature
In-Reply-To: <23044378.1216376452176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6499507.1244627047822.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/GPD-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471376#action_12471376 ] 

Tom Baeyens commented on GPD-226:
---------------------------------

what exactly does this mean ?  you already have a build, right ?

> Define a repeatable build for these plugins to be exported as a feature
> -----------------------------------------------------------------------
>
>                 Key: GPD-226
>                 URL: https://jira.jboss.org/jira/browse/GPD-226
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 08:21:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 10 Jun 2009 08:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1427) Journal
	Cleanup
In-Reply-To: <6551971.1222785211162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29087911.1244636516999.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1427:
---------------------------------

    Issue Type: Task  (was: Feature Request)
      Priority: Major  (was: Critical)


> Journal Cleanup
> ---------------
>
>                 Key: JBMESSAGING-1427
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1427
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> If a destination is lazy, not consuming messages for a long time, the journal will grow until those messages are consumed.
> This would be a problem with DLQs or messages taking days before they are consumed.
> Since we inform the TransactionSummary on commits, we could change the journal to support multiple current-files based on configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 09:55:56 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 10 Jun 2009 09:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6877) EJB3 Entity Cache
	Metrics
In-Reply-To: <13995931.1241642506748.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31109228.1244642156949.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471443#action_12471443 ] 

Charles Crouch commented on JBAS-6877:
--------------------------------------

We're going to try using the generic JBossCache plugin to expose these EJB3 Entity Tree Cache metrics since there isnt anything actually specify to Entities being collected

> EJB3 Entity Cache Metrics
> -------------------------
>
>                 Key: JBAS-6877
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6877
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>            Reporter: Andrew Lee Rubinger
>            Assignee: Brian Stansberry
>             Fix For: Backlog
>
>
> These statistics must be reflected in the admin-console/Jopr.
> Split from JBAS-6624:
> EJB3 Entity Tree Cache (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache-->
> <metric property="NumberOfLocksHeld" displayType="summary"/>
>          <metric property="NumberOfNodes" displayType="summary"/>
> EJB3 Entity Tree Cache Interceptor (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache,treecache-interceptor=CacheMgmtInterceptor-->
>             <metric property="HitMissRatio" displayType="summary" units="percentage"
>                     description="Returns the hit/miss ratio for the cache. This ratio is defined as hits/(hits + misses)."/>
>             <metric property="ReadWriteRatio" displayType="summary" units="percentage"
>                     description="Returns the read/write ratio for the cache. This ratio is defined as (hits + misses)/stores."/>
>             <metric property="Hits" displayType="summary"/>
>             <metric property="Misses" displayType="summary"/>
>             <metric property="Evictions" displayType="summary"/>
>             <metric property="NumberOfLocksHeld"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="AverageWriteTime" units="milliseconds"/>
>             <metric property="TimeSinceReset" units="seconds"/>
>             <metric property="AverageReadTime" units="milliseconds"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="Stores"/>
>             <metric property="NumberOfAttributes"/>
>             <metric property="ElapsedTime" units="milliseconds"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 09:30:56 2009
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Wed, 10 Jun 2009 09:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-141) Servlet Filter
 against XSS and CSRF
Message-ID: <23720221.1244640656753.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remy Maucherat updated JBWEB-141:
---------------------------------

    Security: Public  (was: JBoss Internal)
    Priority: Minor  (was: Major)


> Servlet Filter against XSS and CSRF
> -----------------------------------
>
>                 Key: JBWEB-141
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-141
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Marc Schoenefeld
>            Assignee: Remy Maucherat
>            Priority: Minor
>
> Cross-Site scripting and cross-site request forgery attacks are common threat to every web application. 
> So a common solution offered by the http server is helpful to raise the default protection level. 
> A servlet filter will help to  
> a) allow/block requests for a set of XSS regex patterns (per default blacklist suspicious parameter patterns, and optionally whitelist valid requests for well-known applications)  
> b) allow/block requests that fulfil the criteria for being a forged request (failing nonce compare), this will need a javascript helper on the client side, to transparently protect existing applications to provide the shared secret in the session . 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 08:21:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 10 Jun 2009 08:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1645)
	Multi-threaded replication
In-Reply-To: <19987581.1244635916851.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <343194.1244636516675.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1645:
---------------------------------

    Priority: Critical  (was: Major)


> Multi-threaded replication
> --------------------------
>
>                 Key: JBMESSAGING-1645
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1645
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Currently replication between live and backup node is done on a single thread. The operation is replicated, executed on backup, and when the result is returned to live, it is executed on live before the result is returned to the client (if applicable). This ensures the same ordering of state changes on live and backup but effectively makes all operation single threaded, thus reducing throughput in a clustered set-up.
> Instead we should implement multi-threaded replication. If replicated operations are being executed concurrently on backup it is more tricky to ensure that state changes on any object occur in the  same order as on live but it is possible.
> This is how we can do it.
> For the following types of objects it is important that their state changes occur in the same order on live and backup
> 1) Sessions (S)
> 2) Queues (Q)
> 3) Post offices. (P)
> Operations that occur on the live node are either
> a) Initiated externally - e.g. an operation like send message or acknowledge coming from a client
> b) Initiated internally - e.g. an asynchronous delivery, a depage, or an asynchronous message expiry from the reaper
> As any of these operations are being executed they may affect the state of one or more stateful objects, e.g. a send operation might affect the state of S1, Q1, Q2, S2, and S3 (as a sent message is routed to Q1 and Q2 and immediately delivered to S2 and S3).
> When the operation is replicated to the backup we must ensure that the state changes on any affected stateful objects must occur in the same order as they did on live.
> To do this as the operation is executed and the state changes occur, each stateful object is locked in turn, and a sequence number is obtained from the stateful object which tells us we're the nth stateful operation on that object.
> So a send operation might end up with a set of state sequences numbers:
> S1(12), Q1(102), Q2(32), S2 (74), S3 (1038)
> Which tells us the operation cause the 12th state change on object S1, followed by the 102nd state change on object Q1 etc.
> The list of sequence numbers can be stored in a thread local as the operation is executed on live.
> When the operation is executed on live we delay sending back any data to the client until we have replicate the operation to the backup and got a response that the replication has been processed.
> To ensure the state changes occur in the same order on backup, when we replicate the operation we also replicate the list state sequence numbers. When the operation is executed on the backup we attempt to obtain the locks on the stateful objects.
> Say we try to get the lock on object Q1, but the current sequence number of the object Q1 on the backup is 100, the attempt to get the lock will block until the 101st state change is executed since we require that operation is the 102nd state change.
> By using such a technique we can ensure that state changes are obtained in the same order on live and backup but are not limited to a single thread.
> In many cases the objects will be in the expected or similar sequence numbers so the replications can occur in parallel.
> In case of failure of the live node, operations may block indefinitely on the backup waiting for replications to arrive for missing state changes.
> For this we can timeout on the lock and reverse state changes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:31:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 10 Jun 2009 10:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1603) Rename
 resource MBeans and controls
In-Reply-To: <16977292.1240410748899.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24108308.1244644316767.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1603.
------------------------------------

    Resolution: Done


fixed in the trunk (see changelog)

> Rename resource MBeans and controls
> -----------------------------------
>
>                 Key: JBMESSAGING-1603
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1603
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> JBM resources are managed either using JMX or JBM Core connections.
> The interfaces follow JMX standard (ending with MBean) even when JBM is not managed through JMX.
> We should rename the management interface XXXMBean to XXXControl and their implementation XXXControl to XXXControlImpl
> (e.g. the resource to manage a queue will have a QueueControl interface and a QueueControlImpl implementation)
> This will continue to work with JMX since we use the StandardMBean to create the MBean registered in the MBeanServer

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:27:56 2009
From: jira-events at lists.jboss.org (Penkov Vladimir (JIRA))
Date: Wed, 10 Jun 2009 10:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2421) tomahawk doesn't
 see users's roles
Message-ID: <31888261.1244644076879.JavaMail.jira@cloud.prod.atl2.jboss.com>

tomahawk doesn't see users's roles
----------------------------------

                 Key: JBPORTAL-2421
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2421
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Security
    Affects Versions: 2.7.2 Final
            Reporter: Penkov Vladimir


Create user, give him 'User' role. 
Create jsf portlet with jsfbridge. Add to some page:

<t:commandLink ... enabledOnUserRole="User">


Authenticate as created user. Visit this page. Link will always be disabled.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 09:58:13 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 10 Jun 2009 09:58:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-353) contribute xsd to xml
 catalog (xsd dependent on runtime)
In-Reply-To: <22572021.1244570156492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8416951.1244642293233.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/GPD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-353:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)


> contribute xsd to xml catalog (xsd dependent on runtime)
> --------------------------------------------------------
>
>                 Key: GPD-353
>                 URL: https://jira.jboss.org/jira/browse/GPD-353
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 07:44:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 10 Jun 2009 07:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1613) Make sure
 JMSServerControl
 and MessagingControl create cf methods map to constructors
In-Reply-To: <12784878.1241164606530.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7982311.1244634296704.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1613.
------------------------------------

    Resolution: Out of Date


> Make sure JMSServerControl and MessagingControl create cf methods map to constructors
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1613
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1613
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0.GA
>
>
> Currently the create connection factory methods on the core and JMS controls seem pretty arbitrary and do not map to the cf constructors - change it so they do.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 09:53:56 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 10 Jun 2009 09:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7005) Logging categories
In-Reply-To: <4751763.1244554557239.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1077323.1244642036496.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed JBAS-7005.
------------------------------



I reviewed the changes with Jesper and they looked good.

> Logging categories
> ------------------
>
>                 Key: JBAS-7005
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7005
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Jesper Pedersen
>            Assignee: Scott Marlow
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The jboss-log4j.xml should contain categories to limit the logging of all classes used during startup.
> An example what is missing currently is
>    <!-- Limit Arjuna
>    <category name="com.arjuna">
>       <priority value="INFO"/>
>    </category>
>    -->

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 08:21:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 10 Jun 2009 08:21:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1504) Full Journal
	Compactation
In-Reply-To: <33137475.1234453664451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3881071.1244636517256.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1504:
---------------------------------

    Priority: Major  (was: Critical)


> Full Journal Compactation
> -------------------------
>
>                 Key: JBMESSAGING-1504
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1504
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:27:57 2009
From: jira-events at lists.jboss.org (Penkov Vladimir (JIRA))
Date: Wed, 10 Jun 2009 10:27:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2421) tomahawk
 doesn't see users's roles
In-Reply-To: <31888261.1244644076879.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33195251.1244644077477.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471449#action_12471449 ] 

Penkov Vladimir commented on JBPORTAL-2421:
-------------------------------------------

Using debug I can see that principal has role 'User'. But tomahawk doesn't see it

> tomahawk doesn't see users's roles
> ----------------------------------
>
>                 Key: JBPORTAL-2421
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2421
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Security
>    Affects Versions: 2.7.2 Final
>            Reporter: Penkov Vladimir
>
> Create user, give him 'User' role. 
> Create jsf portlet with jsfbridge. Add to some page:
> <t:commandLink ... enabledOnUserRole="User">
> Authenticate as created user. Visit this page. Link will always be disabled.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:39:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 10 Jun 2009 10:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26703280.1244644796790.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBXB-206:
---------------------------------

    Attachment: jbossxb.zip


> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>         Attachments: jboss-profiler.properties, jbossxb.zip
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:39:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 10 Jun 2009 10:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-206) Performance work
Message-ID: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>

Performance work
----------------

                 Key: JBXB-206
                 URL: https://jira.jboss.org/jira/browse/JBXB-206
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Task
    Affects Versions: JBossXB-2.0.1.GA
            Reporter: Jesper Pedersen
         Attachments: jboss-profiler.properties, jbossxb.zip

I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.

Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:39:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 10 Jun 2009 10:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14353582.1244644796922.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBXB-206:
---------------------------------

    Attachment: jboss-profiler.properties


> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>         Attachments: jboss-profiler.properties, jbossxb.zip
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:47:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 10 Jun 2009 10:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1318) Create
 convenient overloaded methods in core client API
In-Reply-To: <19876864.1211905249734.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12909505.1244645276594.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1318.
------------------------------------

    Resolution: Done


ClientSessionFactory now has a simple constructor and the parameters can be set before the
factory i used (similar to JMS connection.setClientID())

> Create convenient overloaded methods in core client API
> -------------------------------------------------------
>
>                 Key: JBMESSAGING-1318
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1318
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> Create convenient overloaded methods for createProducer, createCOnsumer etc. Which take default values, for ease of use.
> Also allow normal Strings to be used in API.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:51:57 2009
From: jira-events at lists.jboss.org (Penkov Vladimir (JIRA))
Date: Wed, 10 Jun 2009 10:51:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2421) tomahawk doesn't
 see users's roles
In-Reply-To: <31888261.1244644076879.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10169698.1244645517073.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Penkov Vladimir updated JBPORTAL-2421:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156827


> tomahawk doesn't see users's roles
> ----------------------------------
>
>                 Key: JBPORTAL-2421
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2421
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Security
>    Affects Versions: 2.7.2 Final
>            Reporter: Penkov Vladimir
>
> Create user, give him 'User' role. 
> Create jsf portlet with jsfbridge. Add to some page:
> <t:commandLink ... enabledOnUserRole="User">
> Authenticate as created user. Visit this page. Link will always be disabled.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 10:59:57 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 10 Jun 2009 10:59:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6877) EJB3 Entity Cache
	Metrics
In-Reply-To: <13995931.1241642506748.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27393695.1244645997121.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471461#action_12471461 ] 

Brian Stansberry commented on JBAS-6877:
----------------------------------------

Hibernate provides an org.hibernate.jmx.StatisticsServiceMBean which provides all sorts of information about a SessionFactory, including an org.hibernate.stat.SecondLevelCacheStatistics for each entity or collection type that is cached, plus one for each query cache region.

I'm investigating whether we register this MBean as part of SessionFactory/EntityManager deployment.

> EJB3 Entity Cache Metrics
> -------------------------
>
>                 Key: JBAS-6877
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6877
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>            Reporter: Andrew Lee Rubinger
>            Assignee: Brian Stansberry
>             Fix For: Backlog
>
>
> These statistics must be reflected in the admin-console/Jopr.
> Split from JBAS-6624:
> EJB3 Entity Tree Cache (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache-->
> <metric property="NumberOfLocksHeld" displayType="summary"/>
>          <metric property="NumberOfNodes" displayType="summary"/>
> EJB3 Entity Tree Cache Interceptor (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache,treecache-interceptor=CacheMgmtInterceptor-->
>             <metric property="HitMissRatio" displayType="summary" units="percentage"
>                     description="Returns the hit/miss ratio for the cache. This ratio is defined as hits/(hits + misses)."/>
>             <metric property="ReadWriteRatio" displayType="summary" units="percentage"
>                     description="Returns the read/write ratio for the cache. This ratio is defined as (hits + misses)/stores."/>
>             <metric property="Hits" displayType="summary"/>
>             <metric property="Misses" displayType="summary"/>
>             <metric property="Evictions" displayType="summary"/>
>             <metric property="NumberOfLocksHeld"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="AverageWriteTime" units="milliseconds"/>
>             <metric property="TimeSinceReset" units="seconds"/>
>             <metric property="AverageReadTime" units="milliseconds"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="Stores"/>
>             <metric property="NumberOfAttributes"/>
>             <metric property="ElapsedTime" units="milliseconds"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 11:17:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 10 Jun 2009 11:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16219014.1244647076636.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBXB-206:
---------------------------------

    Attachment: server.log.gz


Trace log for JBossXB only

> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>         Attachments: jboss-profiler.properties, jbossxb.zip, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 11:23:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 10 Jun 2009 11:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6960) once a Topic or
 Queue has been
 stopped via the 'stop' operation, none of its operations or properties
 work, and thus it cannot be restarted using the 'start' operation
In-Reply-To: <11989891.1242832445240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <234885.1244647436632.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471469#action_12471469 ] 

Ian Springer commented on JBAS-6960:
------------------------------------

According to Emanuel, this will be fixed once we upgrade to a new version of the Microcontainer. He is going to coordinate this with Ales.



> once a Topic or Queue has been stopped via the 'stop' operation, none of its operations or properties work, and thus it cannot be restarted using the 'start' operation
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6960
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6960
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Ian Springer
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 11:27:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 11:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6784) Add support for JMS
 ServerPeer
 managed object to support enabling metric collection through the console
In-Reply-To: <4119905.1239740302404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26361501.1244647676738.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark reassigned JBAS-6784:
-----------------------------------

    Assignee: Scott M Stark  (was: Jason T. Greene)


> Add support for JMS ServerPeer managed object to support enabling metric collection through the console
> -------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6784
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6784
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Charles Crouch
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> See 
> https://jira.jboss.org/jira/browse/JBAS-6720?focusedCommentId=12461916#action_12461916
> https://jira.jboss.org/jira/browse/JBAS-6720?focusedCommentId=12461917#action_12461917
> for more info on why this would be a good thing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 11:33:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 10 Jun 2009 11:33:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMDR-56)
 AnnotatedElementMetadataLoader
 can be improved to handle DeclaredMethodSignature better
In-Reply-To: <4694138.1244634656561.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27888779.1244648037046.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMDR-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBMDR-56.
-------------------------------

    Fix Version/s: JBossMDR-2.2.0.Beta1
       Resolution: Done


Done in both Branch_2_0 and trunk

> AnnotatedElementMetadataLoader can be improved to handle DeclaredMethodSignature better
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMDR-56
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-56
>             Project: JBoss MetaData Repository
>          Issue Type: Task
>          Components: Loader
>    Affects Versions: JBossMDR-2.0.1.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossMDR-2.2.0.Beta1
>
>
> Currently the AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval for a DeclaredMethodSignature calls the findMethod which results in first getting all methods of the class and then iterating over them to find the right one. This can be improved to instead call the getDeclaredMethod on the class since the DeclaredMethodSignature has the information about which class declares the method.
> Please see the referenced forum thread for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 11:40:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 11:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6242) invoke() for
 "listFormattedSubPoolStatistics" ManagedOperation on datasources and
 connection factory ManagedComponents returns a MetaValue with the wrong
 MetaType
In-Reply-To: <18716075.1227550606927.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4812473.1244648456835.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-6242.
---------------------------------

    Resolution: Deferred


I'm marking this resolved with deferred status as it essentially is an issue of documenting how the managed object layer needs to be configured to use a meta mapper to enforce a consistent metatype. See the associated discussion forum thread.


> invoke() for "listFormattedSubPoolStatistics" ManagedOperation on datasources and connection factory ManagedComponents returns a MetaValue with the wrong MetaType
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6242
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6242
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBAS5 Hudson build dated 200811210604
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This is another case of the data not matching the metadata.
> operation.getReturnType() returns a MutableCompositeMetaType w/ typeName java.lang.Object. However, invoke() is returning a SimpleMetaType.STRING (with value e.g. "Sub Pool Statistics: \nSub Pool Count: 0\n------------------------------------------------------\n"). 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 11:40:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 11:40:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6242) invoke() for
 "listFormattedSubPoolStatistics" ManagedOperation on datasources and
 connection factory ManagedComponents returns a MetaValue with the wrong
 MetaType
In-Reply-To: <18716075.1227550606927.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21541782.1244648457047.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark updated JBAS-6242:
--------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236776


> invoke() for "listFormattedSubPoolStatistics" ManagedOperation on datasources and connection factory ManagedComponents returns a MetaValue with the wrong MetaType
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6242
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6242
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBAS5 Hudson build dated 200811210604
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This is another case of the data not matching the metadata.
> operation.getReturnType() returns a MutableCompositeMetaType w/ typeName java.lang.Object. However, invoke() is returning a SimpleMetaType.STRING (with value e.g. "Sub Pool Statistics: \nSub Pool Count: 0\n------------------------------------------------------\n"). 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 12:03:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 10 Jun 2009 12:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
Message-ID: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>

expose a ManagedObject for EJB3 Entity Beans
--------------------------------------------

                 Key: JBAS-7008
                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Andrew Lee Rubinger
            Priority: Minor


This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 12:07:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 10 Jun 2009 12:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25796535.1244650076748.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7008:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 12:35:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 12:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-191) JAXPDeployer
 should set the setXIncludeAware on the DocumentBuilderFactory
Message-ID: <29577087.1244651756490.JavaMail.jira@cloud.prod.atl2.jboss.com>

JAXPDeployer should set the setXIncludeAware on the DocumentBuilderFactory
--------------------------------------------------------------------------

                 Key: JBDEPLOY-191
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-191
             Project: JBoss Deployers
          Issue Type: Feature Request
          Components: deployer
            Reporter: Anil Saldhana


    Set state of XInclude processing.

    If XInclude markup is found in the document instance, should it be processed as specified in XML Inclusions (XInclude) Version 1.0. (http://www.w3.org/TR/xinclude/)

    XInclude processing defaults to false.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 12:35:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 10 Jun 2009 12:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31054214.1244651756668.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471489#action_12471489 ] 

Andrew Lee Rubinger commented on JBAS-7008:
-------------------------------------------

What do we need exposed?  Any desired behaviour should be reflected in:

http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/testsuite/src/main/org/jboss/test/profileservice/test/Ejb3MetricsUnitTestCase.java

> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:01:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 10 Jun 2009 13:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23158623.1244653316633.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471500#action_12471500 ] 

Ian Springer commented on JBAS-7008:
------------------------------------

Well the minimum would just be one ManagedObject for each entity bean with a 'name' property whose value is the EJB's name. As for metrics, I'm not sure what's available. If the Hibernate stats are not turned on, are there still any other metrics exposed by the EJB3 container for entity beans?


> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:18:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 13:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-128)
 DocumentBuilderFactory.setXIncludeAware set to true
Message-ID: <15329806.1244654336758.JavaMail.jira@cloud.prod.atl2.jboss.com>

DocumentBuilderFactory.setXIncludeAware set to true
---------------------------------------------------

                 Key: JBID-128
                 URL: https://jira.jboss.org/jira/browse/JBID-128
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


DocumentUtil needs to be updated to setXIncludeAware to true on the DocumentBuilderFactory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:18:58 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 13:18:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-128)
 DocumentBuilderFactory.setXIncludeAware set to true
In-Reply-To: <15329806.1244654336758.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12941644.1244654338565.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-128.
------------------------------

    Resolution: Done


> DocumentBuilderFactory.setXIncludeAware set to true
> ---------------------------------------------------
>
>                 Key: JBID-128
>                 URL: https://jira.jboss.org/jira/browse/JBID-128
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> DocumentUtil needs to be updated to setXIncludeAware to true on the DocumentBuilderFactory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:20:57 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 13:20:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-58) Improve
 SOAPSAMLXACMLServlet flexibility
In-Reply-To: <13222478.1235413244235.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2999218.1244654457271.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-58:
------------------------------

    Fix Version/s: IDFED-1.0.0.beta1
                       (was: IDFED-1.0.0.alpha3)


> Improve SOAPSAMLXACMLServlet flexibility
> ----------------------------------------
>
>                 Key: JBID-58
>                 URL: https://jira.jboss.org/jira/browse/JBID-58
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> This servlet can read SAML or XACML requests. It needs to be intelligent enough to figure out the response (whether saml or xacml) based on the type of request that was sent in.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:20:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 13:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-87) Developer FAQ on the
	wiki
In-Reply-To: <25054625.1240933666720.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31157158.1244654456644.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-87:
------------------------------

    Fix Version/s: IDFED-1.0.0.beta1
                       (was: IDFED-1.0.0.alpha3)


> Developer FAQ on the wiki
> -------------------------
>
>                 Key: JBID-87
>                 URL: https://jira.jboss.org/jira/browse/JBID-87
>             Project: JBoss Identity
>          Issue Type: Task
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> Need a developer FAQ to map requirements with the corresponding util/testcase.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:20:57 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 13:20:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-83) Implement token
 encryption (symmetric and public key)
In-Reply-To: <28214881.1240931398900.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4387629.1244654457125.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-83:
------------------------------

    Fix Version/s: IDFED-1.0.0.beta1
                       (was: IDFED-1.0.0.alpha3)


> Implement token encryption (symmetric and public key)
> -----------------------------------------------------
>
>                 Key: JBID-83
>                 URL: https://jira.jboss.org/jira/browse/JBID-83
>             Project: JBoss Identity
>          Issue Type: Task
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha2
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.beta1
>
>
> The request handler must encrypt the tokens generated by the security token provider when needed. We may use the XML Sec API to encrypt the returned tokens.
> Need to look for the XML Signature/Encryption utility for this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:20:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 13:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-85) Implement a script or
 tool to ease to creation of the STS war
In-Reply-To: <29985813.1240933186565.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22907183.1244654456919.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-85:
------------------------------

    Fix Version/s: IDFED-1.0.0.beta1
                       (was: IDFED-1.0.0.alpha3)


> Implement a script or tool to ease to creation of the STS war
> -------------------------------------------------------------
>
>                 Key: JBID-85
>                 URL: https://jira.jboss.org/jira/browse/JBID-85
>             Project: JBoss Identity
>          Issue Type: Task
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha2
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.beta1
>
>
> The JBossSTS is a web service provider that needs to be packaged as a war and include all relevant configuration files (such as web.xml, wsdl, jboss-sts.xml). We need to create a script to assist the user in the process of creating the config files and the STS war that will be deployed on JBoss.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:24:56 2009
From: jira-events at lists.jboss.org (Scott Clasen (JIRA))
Date: Wed, 10 Jun 2009 13:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
Message-ID: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>

unable to restart live/backup pair after clean stop
---------------------------------------------------

                 Key: JBMESSAGING-1646
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0 Beta
         Environment: Standalone JBM 2.0-BETA servers on 2 RHEL 64 bit. JDK 1.6.0_13
            Reporter: Scott Clasen
            Assignee: Tim Fox


Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.

Start Backup--->
 12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
 12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 

Start Live-->
 12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
 12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
 12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 

Backup sees live -->
 12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
 12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
 12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 

Live up->
 12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started

Stop live--->
[sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
[sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 

Stop Backup-->
[sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
[sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
java.lang.NullPointerException
	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
	at java.util.TimerThread.mainLoop(Timer.java:512)
	at java.util.TimerThread.run(Timer.java:462)

Restart Backup-->

15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 

Restart Live-->
12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 


Backup sees Live-->
12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)







-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:27:09 2009
From: jira-events at lists.jboss.org (Scott Clasen (JIRA))
Date: Wed, 10 Jun 2009 13:27:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13329878.1244654829116.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Clasen updated JBMESSAGING-1646:
--------------------------------------

    Attachment: jbm-configuration.xml


This is the jbm-configuration.xml for the live server of the pair

> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta
>         Environment: Standalone JBM 2.0-BETA servers on 2 RHEL 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:27:09 2009
From: jira-events at lists.jboss.org (Scott Clasen (JIRA))
Date: Wed, 10 Jun 2009 13:27:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7402143.1244654829855.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Clasen updated JBMESSAGING-1646:
--------------------------------------

    Attachment: jbm-configuration.xml


this is the jbm-configuration.xml for the backup

> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta
>         Environment: Standalone JBM 2.0-BETA servers on 2 RHEL 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:28:56 2009
From: jira-events at lists.jboss.org (Scott Clasen (JIRA))
Date: Wed, 10 Jun 2009 13:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5385717.1244654936505.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Clasen updated JBMESSAGING-1646:
--------------------------------------

    Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13  (was: Standalone JBM 2.0-BETA servers on 2 RHEL 64 bit. JDK 1.6.0_13)


> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta
>         Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:38:07 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 10 Jun 2009 13:38:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29703161.1244655487624.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1646:
-----------------------------------------

    Fix Version/s: 2.0.0


> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta
>         Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 13:42:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 10 Jun 2009 13:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-87) Developer FAQ on the
	wiki
In-Reply-To: <25054625.1240933666720.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6661036.1244655776475.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-87.
-----------------------------

    Resolution: Done


http://www.jboss.org/community/wiki/JBossIdentityFederation  has the Developer FAQ section.

> Developer FAQ on the wiki
> -------------------------
>
>                 Key: JBID-87
>                 URL: https://jira.jboss.org/jira/browse/JBID-87
>             Project: JBoss Identity
>          Issue Type: Task
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> Need a developer FAQ to map requirements with the corresponding util/testcase.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 14:22:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 10 Jun 2009 14:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-93) Define
 @ManagementProperty ServerConfig.getSpecificationVersion
In-Reply-To: <19526088.1244469536566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18412644.1244658176575.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-93.
---------------------------------------

    Resolution: Done


> Define @ManagementProperty ServerConfig.getSpecificationVersion
> ---------------------------------------------------------------
>
>                 Key: JBBOOT-93
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-93
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-as
>    Affects Versions: 2.0.0-alpha-1
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: impl-as-2.0.0-alpha-2
>
>
> This is required by Jopr.
> 09:32:48,964 WARN  [InventoryManager] Failure during discovery for [JBossAS Server] Resources - failed after 6282 ms.
> java.lang.Exception: Discovery component invocation failed.
>         at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:248)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:123)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.IllegalStateException: Property named 'specificationVersion' not found for ManagedComponent [org.jboss.managed.plugins.ManagedComponentImpl at 24b80637{name=jboss.system:type=ServerConfig, type=ComponentType{type=MCBean, subtype=ServerConfig}, owner=ManagedDeployment at 1381870081}].
>         at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSimplePropertyValue(ManagedComponentUtils.java:73)
>         at org.rhq.plugins.jbossas5.ApplicationServerDiscoveryComponent.discoverInProcessJBossAS(ApplicationServerDiscoveryComponent.java:281)
>         at org.rhq.plugins.jbossas5.ApplicationServerDiscoveryComponent.discoverResources(ApplicationServerDiscoveryComponent.java:102)
>         at sun.reflect.GeneratedMethodAccessor311.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:244)
>         ... 5 more
> Legacy has:
> ctor:
> serverSpecificationVersion = thisPackage.getSpecificationVersion();
> @ManagementProperty(description="the server Specification-Version",
>          use={ViewUse.STATISTIC})
>    public String getSpecificationVersion()
>    {
>       return serverSpecificationVersion;
>    }
> Remove the STATISTIC use and mark read-only.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 14:22:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 10 Jun 2009 14:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7003) Jopr does not start
 in Branch_5_x
In-Reply-To: <8325659.1244469296878.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15273205.1244658176706.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-7003.
---------------------------------------

    Resolution: Done


> Jopr does not start in Branch_5_x
> ---------------------------------
>
>                 Key: JBAS-7003
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7003
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Container task to track any problems relating to Jopr not starting in AS Branch_5_x.
> Any runtime/deploytime failures need a corresponding testcase.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 14:24:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 10 Jun 2009 14:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Work started: (JBPORTAL-2409) Unable to
 delete property without value in portal admin interface
In-Reply-To: <15281741.1244549276551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8148994.1244658296705.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on JBPORTAL-2409 started by Chris Laprun.

> Unable to delete property without value in portal admin interface
> -----------------------------------------------------------------
>
>                 Key: JBPORTAL-2409
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2409
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Web
>    Affects Versions: 2.7.3 Final
>            Reporter: Viliam Rockai
>            Assignee: Chris Laprun
>
> This bug is present in at least three places:
> -Manage properties for all portals
> -Properties of each portal
> -Dashboards  
> in these interfaces it is possible to add values with custom names. when the property is added, it's default value is blank. when a property with blank value is to be deleted (clicking on the delete icon next to the property) nothing will happen. if some value is added to the property, it can be deleted. If you delete the value of some existing property, it can't be deleted.
> after clicking on delete button (page is reloaded) for property without a value, you cannot even delete properties with values until you set values to the blank fields.
> excerpt from the log:
> 14:07:45,694 ERROR [STDERR] Jun 9, 2009 2:07:45 PM javax.faces.component.UIInput updateModel
> SEVERE: /jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean
> java.lang.NullPointerException
> 	at org.jboss.portal.faces.gui.ManagedBean.getLocalizedType(ManagedBean.java:131)
> 	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:85)
> 	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:75)
> 	at org.jboss.portal.core.admin.ui.PropertyBean.setValue(PropertyBean.java:108)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> .........
> 14:07:45,918 INFO  [lifecycle] WARNING: FacesMessage(s) have been enqueued, but may not have been displayed.
> sourceId=_AdminPortletWindow:j_id132:common-manage-prop-form:prop-data-table:0:prop-value-input[severity=(ERROR 2), summary=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean), detail=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean)]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 14:41:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 10 Jun 2009 14:41:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-6982) unable to connect
 to Profile Service remotely using EJB remote interface
In-Reply-To: <33034814.1243442816774.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24494373.1244659317095.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened JBAS-6982:
--------------------------------



I'm still getting a "javax.ejb.EJBAccessException: Caller unauthorized" using either set of credentials.

It looks like the difference may be in the method I'm using to authenticate. I'm setting the principal and credentials in the env props I pass when creating the InitialContext. My client code is at:

  https://svn.jboss.org/repos/jopr/trunk/etc/jbas5-ejb-client/src/main/java/test/EjbClient.java

Whereas in:

   https://svn.jboss.org/repos/jbossas/branches/JBPAPP_5_0/testsuite/src/main/org/jboss/test/profileservice/testsecure/ProfileServiceUnitTestCase.java

you are instead directly using JAAS to authenticate prior to doing the JNDI lookups. Is the method I'm using supposed to work or do I need to switch to the JAAS method?


> unable to connect to Profile Service remotely using EJB remote interface
> ------------------------------------------------------------------------
>
>                 Key: JBAS-6982
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6982
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The non-EJB remote interface is working, with the exception of the various class loading exceptions. The EJB interface is not, due to an authentication failure, but I think it used to work.
> Here's the log output showing me doing the JNDI lookup of the EJB proxies:
> DEBUG 27-05 12:40:03,988 (RemoteProfileServiceConnectionProvider.java:doConnect:90)  -Connecting to Profile Service via remote JNDI using env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:03,988 (AbstractProfileServiceConnectionProvider.java:createInitialContext:74)  -Creating JNDI InitialContext with env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:04,004 (Logger.java:debug:228)  -Using ThreadLocal: false
> DEBUG 27-05 12:40:04,035 (AbstractProfileServiceConnectionProvider.java:createInitialContext:83)  -Created JNDI InitialContext [javax.naming.InitialContext at 1ccb029].
> DEBUG 27-05 12:40:04,035 (Logger.java:debug:228)  -createSocket, hostAddr: /127.0.0.1, port: 1099, localAddr: null, localPort: 0, timeout: 0
> DEBUG 27-05 12:40:04,191 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureProfileService/remote
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Encrypted Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -removed SocketClientInvoker[3820e, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -Created Proxy of type $Proxy1 for EJB3 Business Interface: org.jboss.profileservice.spi.ProfileService
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureManagementView/remote
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -removed SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Created Proxy of type $Proxy3 for EJB3 Business Interface: org.jboss.deployers.spi.management.ManagementView
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureDeploymentManager/remote
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -removed SocketClientInvoker[12940b3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Created Proxy of type $Proxy5 for EJB3 Business Interface: org.jboss.deployers.spi.management.deploy.DeploymentManager
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Couldn't handle invocation directly within org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8: Current invocation "public abstract boolean org.jboss.deployers.spi.management.ManagementView.load()" is not eligible for direct handling by org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Received invocation request to method org.jboss.deployers.spi.management.ManagementView: org.jboss.deployers.spi.management.ManagementView.load(); using hash: -657996635075089079
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -removed SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] disconnecting ...
> And here's the "EJBAccessException: Caller unauthorized" that occurs when I call load() on the ManagementView proxy:
> Exception in thread "main" javax.ejb.EJBAccessException: Caller unauthorized
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:199)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         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:524)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 14:47:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 10 Jun 2009 14:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27099900.1244659676718.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471539#action_12471539 ] 

Tim Fox commented on JBMESSAGING-1646:
--------------------------------------

Thanks Scott-

I'll take a proper look tomorrow, but I think I know what the problem might be. Should be able to get this fixed tomorrow.

> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta
>         Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 15:44:57 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 10 Jun 2009 15:44:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-96) SJC Resource Adapter
	deployer
Message-ID: <17573123.1244663097253.JavaMail.jira@cloud.prod.atl2.jboss.com>

SJC Resource Adapter deployer
-----------------------------

                 Key: JBJCA-96
                 URL: https://jira.jboss.org/jira/browse/JBJCA-96
             Project: JBoss JCA
          Issue Type: Task
          Components: Core
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha1


Create a resource adapter deployer for SJC

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 16:01:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 16:01:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6982) unable to connect
 to Profile Service remotely using EJB remote interface
In-Reply-To: <33034814.1243442816774.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31535993.1244664117256.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471564#action_12471564 ] 

Scott M Stark commented on JBAS-6982:
-------------------------------------

Both approaches should work, so I added a test using the InitialContextFactory and I do see the error you do. I'm looking into that.

> unable to connect to Profile Service remotely using EJB remote interface
> ------------------------------------------------------------------------
>
>                 Key: JBAS-6982
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6982
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The non-EJB remote interface is working, with the exception of the various class loading exceptions. The EJB interface is not, due to an authentication failure, but I think it used to work.
> Here's the log output showing me doing the JNDI lookup of the EJB proxies:
> DEBUG 27-05 12:40:03,988 (RemoteProfileServiceConnectionProvider.java:doConnect:90)  -Connecting to Profile Service via remote JNDI using env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:03,988 (AbstractProfileServiceConnectionProvider.java:createInitialContext:74)  -Creating JNDI InitialContext with env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:04,004 (Logger.java:debug:228)  -Using ThreadLocal: false
> DEBUG 27-05 12:40:04,035 (AbstractProfileServiceConnectionProvider.java:createInitialContext:83)  -Created JNDI InitialContext [javax.naming.InitialContext at 1ccb029].
> DEBUG 27-05 12:40:04,035 (Logger.java:debug:228)  -createSocket, hostAddr: /127.0.0.1, port: 1099, localAddr: null, localPort: 0, timeout: 0
> DEBUG 27-05 12:40:04,191 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureProfileService/remote
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Encrypted Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -removed SocketClientInvoker[3820e, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -Created Proxy of type $Proxy1 for EJB3 Business Interface: org.jboss.profileservice.spi.ProfileService
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureManagementView/remote
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -removed SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Created Proxy of type $Proxy3 for EJB3 Business Interface: org.jboss.deployers.spi.management.ManagementView
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureDeploymentManager/remote
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -removed SocketClientInvoker[12940b3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Created Proxy of type $Proxy5 for EJB3 Business Interface: org.jboss.deployers.spi.management.deploy.DeploymentManager
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Couldn't handle invocation directly within org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8: Current invocation "public abstract boolean org.jboss.deployers.spi.management.ManagementView.load()" is not eligible for direct handling by org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Received invocation request to method org.jboss.deployers.spi.management.ManagementView: org.jboss.deployers.spi.management.ManagementView.load(); using hash: -657996635075089079
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -removed SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] disconnecting ...
> And here's the "EJBAccessException: Caller unauthorized" that occurs when I call load() on the ManagementView proxy:
> Exception in thread "main" javax.ejb.EJBAccessException: Caller unauthorized
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:199)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         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:524)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 16:21:56 2009
From: jira-events at lists.jboss.org (Scott Clasen (JIRA))
Date: Wed, 10 Jun 2009 16:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1647) Correct
 system property
 name in JBMBootstrapServer, add setting of property to start script, add
 config dir to stop script.
Message-ID: <29497109.1244665316669.JavaMail.jira@cloud.prod.atl2.jboss.com>

Correct system property name in JBMBootstrapServer, add setting of property to start script, add config dir to stop script.
---------------------------------------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1647
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1647
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0 Beta
            Reporter: Scott Clasen
            Assignee: Tim Fox


Line 88 of JBMBootstrapServer  is

String dirName = System.getProperty("jbm.bootsrap.bin.dir", ".");

Property should be jbm.bootstrap.bin.dir instead of jbm.bootsrap.bin.dir?

Also the start and stop scripts in the bin dir should probably work by setting this property based on the config dir you use, so KILL_ME gets touched in the config dir

So run.sh should set -Djbm.bootstrap.bin.dir=$CONFIG_DIR

and stop.sh should capture $1 as $CONFIG_DIR and  touch $CONFIG_DIR/KILL_ME

otherwise if you are running 2 configs out of the same distro...like

/messaging-2.0.0.BETA1/bin/run.sh /path/to/config/one &
/messaging-2.0.0.BETA1/bin/run.sh /path/to/config/two &

CURRENT 
/messaging-2.0.0.BETA1/bin/stop.sh  
 //-->BRINGS DOWN BOTH SERVERS

CHANGED
/messaging-2.0.0.BETA1/bin/stop.sh /path/to/config/one 
//-->Brings down only server one








-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 16:38:57 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 10 Jun 2009 16:38:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7009) AS JChannelFactory
 shouldn't subclass the JGroups version
Message-ID: <14168838.1244666337520.JavaMail.jira@cloud.prod.atl2.jboss.com>

AS JChannelFactory shouldn't subclass the JGroups version
---------------------------------------------------------

                 Key: JBAS-7009
                 URL: https://jira.jboss.org/jira/browse/JBAS-7009
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-6.0.0.Alpha1


The AS JChannelFactory class started off as a subclass of the JGroups version with a few small differences. Over time it has added a lot of specialized behavior, and exposing a full-featured ManagedObject interface requires adding significantly more. At this point the benefits of subclassing don't justify the hassle of keeping them coupled.

Both implement the ChannelFactory interface, which is the client view.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 16:42:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 10 Jun 2009 16:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-988) Add API to manipulate
 JChannelFactory stacks member
In-Reply-To: <22228859.1244566736540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1234398.1244666576517.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JGRP-988.
---------------------------------

    Fix Version/s:     (was: 2.6.11)
       Resolution: Won't Fix


Never mind; it's better for the AS to stop subclassing; that works fine: JBAS-7009

> Add API to manipulate JChannelFactory stacks member
> ---------------------------------------------------
>
>                 Key: JGRP-988
>                 URL: https://jira.jboss.org/jira/browse/JGRP-988
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> I'd like to see the following methods added to JChannelFactory to go along with the existing getConfig and removeConfig.  These will allow the JBoss AS-specific subclass to update the contents of the "stacks" member in response to updates from management tools like the embedded console or Jopr:
> public boolean addConfig(String stack_name, String config, boolean replace) {
>    boolean added = replace;
>    if(replace) {
>        stacks.put(st_name, val);
>        if(log.isTraceEnabled())
>            log.trace("added config '" + st_name + "'");
>     }
>     else {
>         if(!stacks.containsKey(st_name)) {
>             stacks.put(st_name, val);
>             added = true;
>             if(log.isTraceEnabled())
>                log.trace("added config '" + st_name + "'");
>     }
>     else {
>          if(log.isTraceEnabled())
>            log.trace("didn't add config '" + st_name + " because one of the same name already existed");
>     }
>     return added;
> }
> public Set<String> getConfigNames() {
>    return Collections.unmodifiableSet(stacks.keySet());
> }
> Bela, I've assigned this to you to get your feedback on it, but I'd be happy to do it. Just assign back to me.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 18:22:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 10 Jun 2009 18:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-2409) Unable to
 delete property without value in portal admin interface
In-Reply-To: <15281741.1244549276551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25994567.1244672576799.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Laprun resolved JBPORTAL-2409.
------------------------------------

    Resolution: Done


> Unable to delete property without value in portal admin interface
> -----------------------------------------------------------------
>
>                 Key: JBPORTAL-2409
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2409
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.7.2 Final
>            Reporter: Viliam Rockai
>            Assignee: Chris Laprun
>             Fix For: 2.7.3 Final
>
>
> This bug is present in at least three places:
> -Manage properties for all portals
> -Properties of each portal
> -Dashboards  
> in these interfaces it is possible to add values with custom names. when the property is added, it's default value is blank. when a property with blank value is to be deleted (clicking on the delete icon next to the property) nothing will happen. if some value is added to the property, it can be deleted. If you delete the value of some existing property, it can't be deleted.
> after clicking on delete button (page is reloaded) for property without a value, you cannot even delete properties with values until you set values to the blank fields.
> excerpt from the log:
> 14:07:45,694 ERROR [STDERR] Jun 9, 2009 2:07:45 PM javax.faces.component.UIInput updateModel
> SEVERE: /jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean
> java.lang.NullPointerException
> 	at org.jboss.portal.faces.gui.ManagedBean.getLocalizedType(ManagedBean.java:131)
> 	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:85)
> 	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:75)
> 	at org.jboss.portal.core.admin.ui.PropertyBean.setValue(PropertyBean.java:108)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> .........
> 14:07:45,918 INFO  [lifecycle] WARNING: FacesMessage(s) have been enqueued, but may not have been displayed.
> sourceId=_AdminPortletWindow:j_id132:common-manage-prop-form:prop-data-table:0:prop-value-input[severity=(ERROR 2), summary=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean), detail=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean)]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 18:22:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 10 Jun 2009 18:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2409) Unable to delete
 property without value in portal admin interface
In-Reply-To: <15281741.1244549276551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3153980.1244672576621.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Laprun updated JBPORTAL-2409:
-----------------------------------

          Component/s: Portal Core Admin
                           (was: Portal Web)
        Fix Version/s: 2.7.3 Final
    Affects Version/s: 2.7.2 Final
                           (was: 2.7.3 Final)


> Unable to delete property without value in portal admin interface
> -----------------------------------------------------------------
>
>                 Key: JBPORTAL-2409
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2409
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.7.2 Final
>            Reporter: Viliam Rockai
>            Assignee: Chris Laprun
>             Fix For: 2.7.3 Final
>
>
> This bug is present in at least three places:
> -Manage properties for all portals
> -Properties of each portal
> -Dashboards  
> in these interfaces it is possible to add values with custom names. when the property is added, it's default value is blank. when a property with blank value is to be deleted (clicking on the delete icon next to the property) nothing will happen. if some value is added to the property, it can be deleted. If you delete the value of some existing property, it can't be deleted.
> after clicking on delete button (page is reloaded) for property without a value, you cannot even delete properties with values until you set values to the blank fields.
> excerpt from the log:
> 14:07:45,694 ERROR [STDERR] Jun 9, 2009 2:07:45 PM javax.faces.component.UIInput updateModel
> SEVERE: /jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean
> java.lang.NullPointerException
> 	at org.jboss.portal.faces.gui.ManagedBean.getLocalizedType(ManagedBean.java:131)
> 	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:85)
> 	at org.jboss.portal.faces.gui.ManagedBean.checkNameValidity(ManagedBean.java:75)
> 	at org.jboss.portal.core.admin.ui.PropertyBean.setValue(PropertyBean.java:108)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> .........
> 14:07:45,918 INFO  [lifecycle] WARNING: FacesMessage(s) have been enqueued, but may not have been displayed.
> sourceId=_AdminPortletWindow:j_id132:common-manage-prop-form:prop-data-table:0:prop-value-input[severity=(ERROR 2), summary=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean), detail=(/jsf/common/editProperties.xhtml @108,130 value="#{prop.value}": Error writing 'value' on type org.jboss.portal.core.admin.ui.PropertyBean)]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 19:30:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 19:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7010)
 JndiLoginInitialContextFactory is
 not creating expected SecurityContext
Message-ID: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>

JndiLoginInitialContextFactory is not creating expected SecurityContext
-----------------------------------------------------------------------

                 Key: JBAS-7010
                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Naming, Security
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Scott M Stark
            Assignee: Scott M Stark


Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 19:34:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 19:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22946726.1244676896447.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-7010.
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Resolution: Done


I updated the JndiLoginInitialContextFactory security actions to be consistent with the ClientLoginModule

> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 19:36:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 10 Jun 2009 19:36:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6982) unable to connect
 to Profile Service remotely using EJB remote interface
In-Reply-To: <33034814.1243442816774.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10889083.1244677017256.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-6982.
---------------------------------

    Resolution: Done


The issue was JBAS-7010, which I have fixed and the test using the JndiLoginInitialContextFactory is now passing

> unable to connect to Profile Service remotely using EJB remote interface
> ------------------------------------------------------------------------
>
>                 Key: JBAS-6982
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6982
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The non-EJB remote interface is working, with the exception of the various class loading exceptions. The EJB interface is not, due to an authentication failure, but I think it used to work.
> Here's the log output showing me doing the JNDI lookup of the EJB proxies:
> DEBUG 27-05 12:40:03,988 (RemoteProfileServiceConnectionProvider.java:doConnect:90)  -Connecting to Profile Service via remote JNDI using env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:03,988 (AbstractProfileServiceConnectionProvider.java:createInitialContext:74)  -Creating JNDI InitialContext with env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
> DEBUG 27-05 12:40:04,004 (Logger.java:debug:228)  -Using ThreadLocal: false
> DEBUG 27-05 12:40:04,035 (AbstractProfileServiceConnectionProvider.java:createInitialContext:83)  -Created JNDI InitialContext [javax.naming.InitialContext at 1ccb029].
> DEBUG 27-05 12:40:04,035 (Logger.java:debug:228)  -createSocket, hostAddr: /127.0.0.1, port: 1099, localAddr: null, localPort: 0, timeout: 0
> DEBUG 27-05 12:40:04,191 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureProfileService/remote
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,254 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,269 (Logger.java:debug:228)  -Could not load JBoss Encrypted Serialization.  Use Java Serialization default.
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -removed SocketClientInvoker[3820e, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[3820e, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -Created Proxy of type $Proxy1 for EJB3 Business Interface: org.jboss.profileservice.spi.ProfileService
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureManagementView/remote
> DEBUG 27-05 12:40:04,301 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -removed SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -SocketClientInvoker[f4f44a, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,316 (Logger.java:debug:228)  -Created Proxy of type $Proxy3 for EJB3 Business Interface: org.jboss.deployers.spi.management.ManagementView
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory servicing request for SecureDeploymentManager/remote
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -removed SocketClientInvoker[12940b3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,332 (Logger.java:debug:228)  -Created Proxy of type $Proxy5 for EJB3 Business Interface: org.jboss.deployers.spi.management.deploy.DeploymentManager
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Couldn't handle invocation directly within org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8: Current invocation "public abstract boolean org.jboss.deployers.spi.management.ManagementView.load()" is not eligible for direct handling by org.jboss.ejb3.proxy.impl.handler.session.SessionRemoteProxyInvocationHandler at 958bb8
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -SocketClientInvoker[12940b3, socket://MAINFRAME:3873] disconnecting ...
> DEBUG 27-05 12:40:04,348 (Logger.java:debug:228)  -Received invocation request to method org.jboss.deployers.spi.management.ManagementView: org.jboss.deployers.spi.management.ManagementView.load(); using hash: -657996635075089079
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] constructed
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connecting
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -Creating semaphore with size 50
> DEBUG 27-05 12:40:04,363 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] connected
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -removed SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] from registry
> DEBUG 27-05 12:40:04,379 (Logger.java:debug:228)  -SocketClientInvoker[18b81e3, socket://MAINFRAME:3873] disconnecting ...
> And here's the "EJBAccessException: Caller unauthorized" that occurs when I call load() on the ManagementView proxy:
> Exception in thread "main" javax.ejb.EJBAccessException: Caller unauthorized
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:199)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         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:524)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.load(Unknown Source)
>         at org.jboss.adminclient.connection.ProfileServiceConnectionImpl.<init>(ProfileServiceConnectionImpl.java:47)
>         at org.jboss.adminclient.connection.RemoteProfileServiceConnectionProvider.doConnect(RemoteProfileServiceConnectionProvider.java:114)
>         at org.jboss.adminclient.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:44)
>         at org.jboss.adminclient.command.ConnectCommand.execute(ConnectCommand.java:73)
>         at org.jboss.adminclient.AdminClientMain.processArguments(AdminClientMain.java:451)
>         at org.jboss.adminclient.AdminClientMain.main(AdminClientMain.java:124)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 20:00:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Wed, 10 Jun 2009 20:00:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREFLECT-53) Replace Arrays
 with varargs on all getDeclaredXXXMethods
Message-ID: <27973728.1244678456555.JavaMail.jira@cloud.prod.atl2.jboss.com>

Replace Arrays with varargs on all getDeclaredXXXMethods
--------------------------------------------------------

                 Key: JBREFLECT-53
                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-53
             Project: JBoss Reflection
          Issue Type: Task
          Components: ClassInfo
    Affects Versions: JBossReflection.2.0.2.GA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: JBossReflection.2.2.0-Beta1 


Similar to what was done on java.lang.Class<?>.getDeclaredMethods(....) and java.lang.Class<?>.getDeclaredConstructors(), we should replace type parameter arrays with varargs on everywhere that is appliable.

This maintains the backwards compatibility with old version, as callers can still use the array, but adds simplicity for new users, that get rid of having to create a type array everytime they need to invoke those methods.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 21:51:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 10 Jun 2009 21:51:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2117) fireAllRules()
 blocks if called while fireUntilHalt() is running
Message-ID: <18433550.1244685116605.JavaMail.jira@cloud.prod.atl2.jboss.com>

fireAllRules() blocks if called while fireUntilHalt() is running
----------------------------------------------------------------

                 Key: JBRULES-2117
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2117
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


Drools work items call fireAllRules() automatically after completion. If the engine is already running fireUntilHalt() though, it blocks.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 22:17:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 10 Jun 2009 22:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
Message-ID: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>

Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
--------------------------------------------------------------

                 Key: JBWEB-142
                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
             Project: JBoss Web
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Tomcat
    Affects Versions: JBossWeb-2.0.0.GA_CP10
            Reporter: Mike Millson
            Assignee: Remy Maucherat


Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).

Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.

Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 22:34:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 10 Jun 2009 22:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2117) fireAllRules()
 blocks if called while fireUntilHalt() is running
In-Reply-To: <18433550.1244685116605.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6071314.1244687696548.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2117.
----------------------------------

    Resolution: Done


Fixed.

> fireAllRules() blocks if called while fireUntilHalt() is running
> ----------------------------------------------------------------
>
>                 Key: JBRULES-2117
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2117
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> Drools work items call fireAllRules() automatically after completion. If the engine is already running fireUntilHalt() though, it blocks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 22:37:07 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 10 Jun 2009 22:37:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2117) fireAllRules()
 blocks if called while fireUntilHalt() is running
In-Reply-To: <18433550.1244685116605.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9651522.1244687827663.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2117.
----------------------------------

    Fix Version/s: 5.0.2
       Resolution: Done


> fireAllRules() blocks if called while fireUntilHalt() is running
> ----------------------------------------------------------------
>
>                 Key: JBRULES-2117
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2117
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.0.2, 5.1.0.M1
>
>
> Drools work items call fireAllRules() automatically after completion. If the engine is already running fireUntilHalt() though, it blocks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 22:37:07 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 10 Jun 2009 22:37:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-2117) fireAllRules()
 blocks if called while fireUntilHalt() is running
In-Reply-To: <18433550.1244685116605.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22107332.1244687827536.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reopened JBRULES-2117:
------------------------------------



> fireAllRules() blocks if called while fireUntilHalt() is running
> ----------------------------------------------------------------
>
>                 Key: JBRULES-2117
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2117
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.0.2, 5.1.0.M1
>
>
> Drools work items call fireAllRules() automatically after completion. If the engine is already running fireUntilHalt() though, it blocks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 10 23:17:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 10 Jun 2009 23:17:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1641) Stopping the
 bridge service doesn't stop the failure handler
In-Reply-To: <31429260.1244473017316.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28752914.1244690277204.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1641.
-----------------------------------

    Resolution: Done


done. Manually tested from JMX console.

> Stopping the bridge service doesn't stop the failure handler
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1641
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1641
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> when bridge is stopped via the JMX, the stop() action doesn't stop the failure handler, which will keep trying to reconnect even after bridge service has been stopped.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 01:59:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 11 Jun 2009 01:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBREFLECT-3) Use the
 ScopedClassPool from javassist
In-Reply-To: <12331947.1165415635891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17279629.1244699996729.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBREFLECT-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin reassigned JBREFLECT-3:
-----------------------------------

    Assignee: Flavia Rainone  (was: Ales Justin)


> Use the ScopedClassPool from javassist
> --------------------------------------
>
>                 Key: JBREFLECT-3
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-3
>             Project: JBoss Reflection
>          Issue Type: Task
>          Components: Javassist
>            Reporter: Adrian Brock
>            Assignee: Flavia Rainone
>
> The javassist reflection utilities use the original shared classpool.
> This does not understand classloaders.
> This should be updated to use the newer ScopedClassPool from javassist.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 01:59:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 11 Jun 2009 01:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBREFLECT-6) Javassist based
 reflection objects uses the compiler
In-Reply-To: <5081114.1165415515640.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24519883.1244699997005.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBREFLECT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin reassigned JBREFLECT-6:
-----------------------------------

    Assignee: Flavia Rainone  (was: Ales Justin)


> Javassist based reflection objects uses the compiler
> ----------------------------------------------------
>
>                 Key: JBREFLECT-6
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-6
>             Project: JBoss Reflection
>          Issue Type: Task
>          Components: Javassist
>            Reporter: Adrian Brock
>            Assignee: Flavia Rainone
>
> The JavassistReflectionFactory builds up a source to compile the method, constructor and field accesors.
> These implementations are faster than the normal reflection equivalents, but using the compiler is slow.
> These methods should be optimized to generate the bytecode directly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 02:03:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 11 Jun 2009 02:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <15323501.1244700236973.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471627#action_12471627 ] 

Howard Gao commented on JBMESSAGING-1631:
-----------------------------------------

Hi Victor,

Just an update. My test has been running over night without message pile up at either node. I found the client failover didn't happen as my two machines are in a local network. 

I'll further reduce the ping timeout (already 500ms). However, as the MDB is deployed within the App Server. If the MDB is connected to the same Server, it's unlikely that client failover will happen.
One possible reason that may affect the message sucker is that if the message sucker's connection has ping timeout. I'll try to make this happen to see if I can made any progress.

Alse please note you should use remoting 2.2.3. remoting 2.5.1 doesn't include all the fixes for JBMESSAGING-1456.

> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 02:06:07 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 11 Jun 2009 02:06:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1847) Fix logging of
 irrelevant (for end users) message about WebService context property
Message-ID: <20139007.1244700367599.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix logging of irrelevant (for end users) message about WebService context property  
-------------------------------------------------------------------------------------

                 Key: EJBTHREE-1847
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1847
             Project: EJB 3.0
          Issue Type: Task
          Components: core
    Affects Versions: 1.1.6
            Reporter: jaikiran pai
            Assignee: jaikiran pai


We currently log this message 

[StatelessBeanContext]  EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected

which is of no relevance to the end user. We need to fix this. Please see referenced forum thread for details.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 02:37:56 2009
From: jira-events at lists.jboss.org (Penkov Vladimir (JIRA))
Date: Thu, 11 Jun 2009 02:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2421) tomahawk
 doesn't see users's roles
In-Reply-To: <31888261.1244644076879.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9500023.1244702276768.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471634#action_12471634 ] 

Penkov Vladimir commented on JBPORTAL-2421:
-------------------------------------------

One must add

        <security-role-ref>
            <role-name>User</role-name>
        </security-role-ref>

to portlet.xml

> tomahawk doesn't see users's roles
> ----------------------------------
>
>                 Key: JBPORTAL-2421
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2421
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Security
>    Affects Versions: 2.7.2 Final
>            Reporter: Penkov Vladimir
>
> Create user, give him 'User' role. 
> Create jsf portlet with jsfbridge. Add to some page:
> <t:commandLink ... enabledOnUserRole="User">
> Authenticate as created user. Visit this page. Link will always be disabled.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 03:29:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 11 Jun 2009 03:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1647) Correct
 system property
 name in JBMBootstrapServer, add setting of property to start script, add
 config dir to stop script.
In-Reply-To: <29497109.1244665316669.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28815159.1244705396671.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1647:
---------------------------------

    Fix Version/s: 2.0.0
         Assignee: Andy Taylor  (was: Tim Fox)


> Correct system property name in JBMBootstrapServer, add setting of property to start script, add config dir to stop script.
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1647
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1647
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta
>            Reporter: Scott Clasen
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>
> Line 88 of JBMBootstrapServer  is
> String dirName = System.getProperty("jbm.bootsrap.bin.dir", ".");
> Property should be jbm.bootstrap.bin.dir instead of jbm.bootsrap.bin.dir?
> Also the start and stop scripts in the bin dir should probably work by setting this property based on the config dir you use, so KILL_ME gets touched in the config dir
> So run.sh should set -Djbm.bootstrap.bin.dir=$CONFIG_DIR
> and stop.sh should capture $1 as $CONFIG_DIR and  touch $CONFIG_DIR/KILL_ME
> otherwise if you are running 2 configs out of the same distro...like
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/one &
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/two &
> CURRENT 
> /messaging-2.0.0.BETA1/bin/stop.sh  
>  //-->BRINGS DOWN BOTH SERVERS
> CHANGED
> /messaging-2.0.0.BETA1/bin/stop.sh /path/to/config/one 
> //-->Brings down only server one

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 04:10:59 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 11 Jun 2009 04:10:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-207) Default
 SchemaBindingResolver impl may loose location/uri to class mapping
Message-ID: <28200716.1244707859087.JavaMail.jira@cloud.prod.atl2.jboss.com>

Default SchemaBindingResolver impl may loose location/uri to class mapping
--------------------------------------------------------------------------

                 Key: JBXB-207
                 URL: https://jira.jboss.org/jira/browse/JBXB-207
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.1.GA
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossXB-2.0.2.GA


MultiClassSchemaResolver and DefaultSchemaResolver use WeakHashMap for uriToClass and schemaLocationToClass maps. Both of them are supposed to contain mappings set by a user using public methods mapLocationToClass(String schemaLocation, Class<?> clazz), mapURIToClass(String nsUri, Class<?> clazz), etc. None of the maps is used as an internal cache during schema binding resolution, i.e. if a schema binding is resolved w/o a user-provided mapping the mapping could be added/cached into those maps (successfully resolved schemas are cached by their ns URI instead).
So, the fact that a user-provided mapping can disappear is confusing and wrong.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 06:34:57 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Thu, 11 Jun 2009 06:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1647) Correct system
 property
 name in JBMBootstrapServer, add setting of property to start script, add
 config dir to stop script.
In-Reply-To: <29497109.1244665316669.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1353769.1244716497193.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1647.
------------------------------------

    Resolution: Done


fixed. Ive renamed the kill_me file to STOP_ME and it is now put under the config directory

> Correct system property name in JBMBootstrapServer, add setting of property to start script, add config dir to stop script.
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1647
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1647
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta
>            Reporter: Scott Clasen
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>
> Line 88 of JBMBootstrapServer  is
> String dirName = System.getProperty("jbm.bootsrap.bin.dir", ".");
> Property should be jbm.bootstrap.bin.dir instead of jbm.bootsrap.bin.dir?
> Also the start and stop scripts in the bin dir should probably work by setting this property based on the config dir you use, so KILL_ME gets touched in the config dir
> So run.sh should set -Djbm.bootstrap.bin.dir=$CONFIG_DIR
> and stop.sh should capture $1 as $CONFIG_DIR and  touch $CONFIG_DIR/KILL_ME
> otherwise if you are running 2 configs out of the same distro...like
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/one &
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/two &
> CURRENT 
> /messaging-2.0.0.BETA1/bin/stop.sh  
>  //-->BRINGS DOWN BOTH SERVERS
> CHANGED
> /messaging-2.0.0.BETA1/bin/stop.sh /path/to/config/one 
> //-->Brings down only server one

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 06:34:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 11 Jun 2009 06:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1648) Bridge may
 stop working after long time idle
Message-ID: <30049000.1244716497603.JavaMail.jira@cloud.prod.atl2.jboss.com>

Bridge may stop working after long time idle
--------------------------------------------

                 Key: JBMESSAGING-1648
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1648
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Facade
    Affects Versions: 1.4.3.GA
            Reporter: Howard Gao
            Assignee: Howard Gao
             Fix For: 1.4.5.GA


Bridge service may stop working after a long time idle

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 06:56:56 2009
From: jira-events at lists.jboss.org (Joao Paulo Viragine (JIRA))
Date: Thu, 11 Jun 2009 06:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2422) Change the name
 of casServerName parameter to casClientServerName/casClientName in
 CASAuthenticationValve
Message-ID: <16318858.1244717816473.JavaMail.jira@cloud.prod.atl2.jboss.com>

Change the name of casServerName parameter to casClientServerName/casClientName in CASAuthenticationValve
---------------------------------------------------------------------------------------------------------

                 Key: JBPORTAL-2422
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2422
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.7.2 Final
            Reporter: Joao Paulo Viragine




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 07:18:56 2009
From: jira-events at lists.jboss.org (Joao Paulo Viragine (JIRA))
Date: Thu, 11 Jun 2009 07:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2422) Change the name
 of casServerName parameter to casClientServerName/casClientName in
 CASAuthenticationValve
In-Reply-To: <16318858.1244717816473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30816297.1244719136685.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joao Paulo Viragine updated JBPORTAL-2422:
------------------------------------------

    Description: 
Maybe separate the declaration of server and port.

Something like: casClientServerName and casClientPortNumber

Or as suggested by Posolda: casClientName. (for client server name and port)


> Change the name of casServerName parameter to casClientServerName/casClientName in CASAuthenticationValve
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2422
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2422
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.7.2 Final
>            Reporter: Joao Paulo Viragine
>
> Maybe separate the declaration of server and port.
> Something like: casClientServerName and casClientPortNumber
> Or as suggested by Posolda: casClientName. (for client server name and port)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 07:48:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 11 Jun 2009 07:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1847) Fix the issue
 that causes
 StatelessBeanContext to log a WARN message about WebServiceContext property
In-Reply-To: <20139007.1244700367599.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7575972.1244720936697.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1847:
-----------------------------------

        Summary: Fix the issue that causes StatelessBeanContext to log a WARN message about WebServiceContext property  (was: Fix logging of irrelevant (for end users) message about WebService context property  )
    Description: 
We currently log this message 

[StatelessBeanContext]  EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected

which is of no relevance to the end user. We need to fix the the real issue which causes this log. Please see the referenced forum thread for details.


  was:
We currently log this message 

[StatelessBeanContext]  EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected

which is of no relevance to the end user. We need to fix this. Please see referenced forum thread for details.




> Fix the issue that causes StatelessBeanContext to log a WARN message about WebServiceContext property
> -----------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1847
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1847
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core
>    Affects Versions: 1.1.6
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> We currently log this message 
> [StatelessBeanContext]  EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected
> which is of no relevance to the end user. We need to fix the the real issue which causes this log. Please see the referenced forum thread for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 07:52:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 11 Jun 2009 07:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-989) TCPPING: add new
 member addresses to initial_hosts dynamically
Message-ID: <31320194.1244721176847.JavaMail.jira@cloud.prod.atl2.jboss.com>

TCPPING: add new member addresses to initial_hosts dynamically
--------------------------------------------------------------

                 Key: JGRP-989
                 URL: https://jira.jboss.org/jira/browse/JGRP-989
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


When we have A,B and C listed in initial_hosts but later D and E join, and we have a partition {A,B,C} and {D,E}, when the partition heals later, we have no way of merging the 2 subgroups back into 1 because initial_hosts doesn't contain D or E.
SOLUTION: dynamically add members not in initial_hosts to initial_hosts on view changes. Keep the number of dynamically added members bounded.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 07:59:12 2009
From: jira-events at lists.jboss.org (Vijayanandraj Amaladoss (JIRA))
Date: Thu, 11 Jun 2009 07:59:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBWEB-143) ThreadName in
	AccessLogValve
Message-ID: <5445829.1244721552450.JavaMail.jira@cloud.prod.atl2.jboss.com>

 ThreadName in AccessLogValve
-----------------------------

                 Key: JBWEB-143
                 URL: https://jira.jboss.org/jira/browse/JBWEB-143
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Core
    Affects Versions: JBossWeb-2.0.0.GA
         Environment: Jboss 4.2 GA EAP / Any operating system
            Reporter: Vijayanandraj Amaladoss
            Assignee: Remy Maucherat


Writing the thread name in the access log using "%I" pattern is not supported in Jboss web 2.0 GA. This is implemented in Jboss web 2.1.2 GA.

Please refer to thread

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236960'




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 08:02:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 11 Jun 2009 08:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-207) Default
 SchemaBindingResolver impl may loose location/uri to class mapping
In-Reply-To: <28200716.1244707859087.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11009975.1244721776464.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBXB-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBXB-207.
----------------------------------

    Resolution: Done


Done.

> Default SchemaBindingResolver impl may loose location/uri to class mapping
> --------------------------------------------------------------------------
>
>                 Key: JBXB-207
>                 URL: https://jira.jboss.org/jira/browse/JBXB-207
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> MultiClassSchemaResolver and DefaultSchemaResolver use WeakHashMap for uriToClass and schemaLocationToClass maps. Both of them are supposed to contain mappings set by a user using public methods mapLocationToClass(String schemaLocation, Class<?> clazz), mapURIToClass(String nsUri, Class<?> clazz), etc. None of the maps is used as an internal cache during schema binding resolution, i.e. if a schema binding is resolved w/o a user-provided mapping the mapping could be added/cached into those maps (successfully resolved schemas are cached by their ns URI instead).
> So, the fact that a user-provided mapping can disappear is confusing and wrong.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 08:52:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 11 Jun 2009 08:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-88) ViewUse getting lost
 during serialization
Message-ID: <21552121.1244724776829.JavaMail.jira@cloud.prod.atl2.jboss.com>

ViewUse getting lost during serialization
-----------------------------------------

                 Key: JBMAN-88
                 URL: https://jira.jboss.org/jira/browse/JBMAN-88
             Project: JBoss Managed
          Issue Type: Bug
    Affects Versions: JBossMan.2.1.1.Beta3
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber


Since the annotations are transient, the ViewUse cannot be rebuilt after serialization. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 08:56:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Thu, 11 Jun 2009 08:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11584321.1244725016429.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened JBAS-7010:
--------------------------------



Can you check the fix into the EAP branch too? That's the branch we're using for Jopr/EmbJopr dev.



> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 09:01:58 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 11 Jun 2009 09:01:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-989) TCPPING: add new
 member addresses to initial_hosts dynamically
In-Reply-To: <31320194.1244721176847.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19331564.1244725318788.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-989.
---------------------------

    Resolution: Done


> TCPPING: add new member addresses to initial_hosts dynamically
> --------------------------------------------------------------
>
>                 Key: JGRP-989
>                 URL: https://jira.jboss.org/jira/browse/JGRP-989
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> When we have A,B and C listed in initial_hosts but later D and E join, and we have a partition {A,B,C} and {D,E}, when the partition heals later, we have no way of merging the 2 subgroups back into 1 because initial_hosts doesn't contain D or E.
> SOLUTION: dynamically add members not in initial_hosts to initial_hosts on view changes. Keep the number of dynamically added members bounded.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 09:21:21 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 11 Jun 2009 09:21:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-205) upgrade to the
	latest xb release
Message-ID: <32952551.1244726484110.JavaMail.jira@cloud.prod.atl2.jboss.com>

upgrade to the latest xb release
--------------------------------

                 Key: JBMETA-205
                 URL: https://jira.jboss.org/jira/browse/JBMETA-205
             Project: JBoss Metadata
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: 1.0.2.Beta2


XB 2.0.2.Beta1 at a minimum.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 09:24:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 11 Jun 2009 09:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-88) ViewUse getting lost
 during serialization
In-Reply-To: <21552121.1244724776829.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28822015.1244726696544.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMAN-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved JBMAN-88.
--------------------------------------

    Fix Version/s: JBossMan.2.1.1.CR1
       Resolution: Done


> ViewUse getting lost during serialization
> -----------------------------------------
>
>                 Key: JBMAN-88
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-88
>             Project: JBoss Managed
>          Issue Type: Bug
>    Affects Versions: JBossMan.2.1.1.Beta3
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossMan.2.1.1.CR1
>
>
> Since the annotations are transient, the ViewUse cannot be rebuilt after serialization. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 09:24:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 11 Jun 2009 09:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-206) TESTSUITE:
 externalize schema to class mapping into a properties file
Message-ID: <10888381.1244726696753.JavaMail.jira@cloud.prod.atl2.jboss.com>

TESTSUITE: externalize schema to class mapping into a properties file
---------------------------------------------------------------------

                 Key: JBMETA-206
                 URL: https://jira.jboss.org/jira/browse/JBMETA-206
             Project: JBoss Metadata
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: 1.0.2.Beta2


All the mapping is currently done in MetaDataSchemaResolverFactory. Working on the metadata split, this class could be in the common but the mapping would be different for a specific subproject.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 09:27:07 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 11 Jun 2009 09:27:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMETA-206) TESTSUITE:
 externalize schema to class mapping into a properties file
In-Reply-To: <10888381.1244726696753.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21969964.1244726827487.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBMETA-206.
------------------------------------

    Resolution: Done


Done.

> TESTSUITE: externalize schema to class mapping into a properties file
> ---------------------------------------------------------------------
>
>                 Key: JBMETA-206
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-206
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.0.2.Beta2
>
>
> All the mapping is currently done in MetaDataSchemaResolverFactory. Working on the metadata split, this class could be in the common but the mapping would be different for a specific subproject.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 09:32:56 2009
From: jira-events at lists.jboss.org (Victor Starenky (JIRA))
Date: Thu, 11 Jun 2009 09:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <1869123.1244727176884.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471684#action_12471684 ] 

Victor Starenky commented on JBMESSAGING-1631:
----------------------------------------------

We've switched to the latest jars for messaging that has fix for  JBMESSAGING-1456 and as well switched all other required libaries including remoting (to the version 2.2.3 as per documentation).
Still this morning we see one node piling up topic messages. As far as I can tell we mostly experience this issue with topics. One or more nodes stop receiving messages and in JMX console we see thousands of them sitting on these nodes.

As I mentioned before we're pushing servers to the limits overnight so timeouts are likely caused by exessive load more than network.

> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 10:00:08 2009
From: jira-events at lists.jboss.org (Zachary Bedell (JIRA))
Date: Thu, 11 Jun 2009 10:00:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-207)
 NullPointerException during
 deployment of EJB3 methods with zero parameters
Message-ID: <31747213.1244728808387.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointerException during deployment of EJB3 methods with zero parameters
---------------------------------------------------------------------------

                 Key: JBMETA-207
                 URL: https://jira.jboss.org/jira/browse/JBMETA-207
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.0.0.GA
         Environment: JBoss-5.1.0-GA, JDK 1.6.0_07-b06-153 (Apple/Sun JVM, 64-bit on OS/X), EJB3 w/ descriptor overrides
            Reporter: Zachary Bedell
            Assignee: Alexey Loubyansky


Deploying an EJB3 based EAR results in an NPE with the below stack trace.  The problem appears to manifest with EJB3's containing methods that take zero arguments.  There are also XML descriptor based attributes for several of the metadata elements.  To the best of my knowledge the descriptors only augment, not override anything specified in annotations.

Patch for this should be trivial (an additional null check on line 83 of RolesAllowedProcessor.java should do it).  I'm in the process of attempting to get JBMETA built from source and integrated into my stack.  Will attach patch & tests unless someone beats me to it.

The stack:

09:44:51,219 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=vfszip:/jboss/jboss-eap-5.0/server/ucmsfc/deploy/ucms.ear/ state=ClassLoader mode=Manual requiredState=PostClassLoader
org.jboss.deployers.spi.DeploymentException: Cannot process metadata
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:181)
	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:93)
	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.install(DeployersImpl.java:1098)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
	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:698)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:59)
	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:355)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
	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:310)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:241)
	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
	at org.jboss.Main.boot(Main.java:216)
	at org.jboss.Main$1.run(Main.java:546)
	at java.lang.Thread.run(Thread.java:637)
Caused by: java.lang.NullPointerException
	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:83)
	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:48)
	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:215)
	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:172)
	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:151)
	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:94)
	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:52)
	at org.jboss.metadata.annotation.creator.AbstractCreator.process(AbstractCreator.java:154)
	at org.jboss.metadata.annotation.creator.AbstractCreator.processMetaData(AbstractCreator.java:87)
	at org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator.create(JBoss50Creator.java:109)
	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processJBossMetaData(OptAnnotationMetaDataDeployer.java:134)
	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processMetaData(OptAnnotationMetaDataDeployer.java:84)
	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:177)
	... 31 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 10:02:56 2009
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Thu, 11 Jun 2009 10:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2118) comment makes
 Work Definition parser fail
Message-ID: <30166236.1244728976467.JavaMail.jira@cloud.prod.atl2.jboss.com>

comment makes Work Definition parser fail
-----------------------------------------

                 Key: JBRULES-2118
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2118
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse (flow)
    Affects Versions: 5.0.1.FINAL
         Environment: Eclipse
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor


See example in Drools Flow, section 8.2.1., Creating the Work Definition: The comment // add more work items here ... makes the parser fail when calling up the RuleFlow editor ("Could not parse work definitions ...: null")


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 10:04:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 11 Jun 2009 10:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMETA-207)
 NullPointerException during
 deployment of EJB3 methods with zero parameters
In-Reply-To: <31747213.1244728808387.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4716605.1244729096611.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky reassigned JBMETA-207:
----------------------------------------

    Assignee: Andrew Lee Rubinger  (was: Alexey Loubyansky)


Andrew, can you look into this?

> NullPointerException during deployment of EJB3 methods with zero parameters
> ---------------------------------------------------------------------------
>
>                 Key: JBMETA-207
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-207
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.0.GA
>         Environment: JBoss-5.1.0-GA, JDK 1.6.0_07-b06-153 (Apple/Sun JVM, 64-bit on OS/X), EJB3 w/ descriptor overrides
>            Reporter: Zachary Bedell
>            Assignee: Andrew Lee Rubinger
>
> Deploying an EJB3 based EAR results in an NPE with the below stack trace.  The problem appears to manifest with EJB3's containing methods that take zero arguments.  There are also XML descriptor based attributes for several of the metadata elements.  To the best of my knowledge the descriptors only augment, not override anything specified in annotations.
> Patch for this should be trivial (an additional null check on line 83 of RolesAllowedProcessor.java should do it).  I'm in the process of attempting to get JBMETA built from source and integrated into my stack.  Will attach patch & tests unless someone beats me to it.
> The stack:
> 09:44:51,219 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=vfszip:/jboss/jboss-eap-5.0/server/ucmsfc/deploy/ucms.ear/ state=ClassLoader mode=Manual requiredState=PostClassLoader
> org.jboss.deployers.spi.DeploymentException: Cannot process metadata
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:181)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:93)
> 	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.install(DeployersImpl.java:1098)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:698)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:59)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:355)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:310)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:241)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 	at org.jboss.Main.boot(Main.java:216)
> 	at org.jboss.Main$1.run(Main.java:546)
> 	at java.lang.Thread.run(Thread.java:637)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:83)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:48)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:215)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:172)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:151)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:94)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:52)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.process(AbstractCreator.java:154)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.processMetaData(AbstractCreator.java:87)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator.create(JBoss50Creator.java:109)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processJBossMetaData(OptAnnotationMetaDataDeployer.java:134)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processMetaData(OptAnnotationMetaDataDeployer.java:84)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:177)
> 	... 31 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 10:15:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 11 Jun 2009 10:15:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1649) redesign
 management replication
Message-ID: <1828892.1244729756776.JavaMail.jira@cloud.prod.atl2.jboss.com>

redesign management replication
-------------------------------

                 Key: JBMESSAGING-1649
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1649
             Project: JBoss Messaging
          Issue Type: Task
    Affects Versions: 2.0.0 Beta
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 2.0.0


In order for management operation using JMX to be replicated, the MBeans are translating the management
operation to a management messages which is sent to the management address using Core API. This allows
for management messages to be properly replicated.

However this allow forces the server to have an acceptor and a connector to talk to *itelsf* which is configusing
and clutter the server configuration.

The management code should be redesigned to be plugged directly on the server-side. The management 
service'd no longer send a Core message using the Core API. Instead it'd call directly the ServerSessionPacketHandler
(or equivalent) to handle a packet corresponding to the management message. It'll work since the handler will then
replicate the packet correctly.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 10:47:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 11 Jun 2009 10:47:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <27683092.1244731677179.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471699#action_12471699 ] 

Howard Gao commented on JBMESSAGING-1631:
-----------------------------------------

Thanks Victor. I'll change to topic then. 

A question: when you find the messaging piling up, did you stop the sending and wait to see if the messages are still there? 

Also my sending program just keep sending messages in a loop, 20 messages for each transaction. is that enough to load the servers?

Howard


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 11:23:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Thu, 11 Jun 2009 11:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11296698.1244733837724.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-7010.
---------------------------------

    Resolution: Done


Done
Sending        security/src/main/org/jboss/security/jndi/JndiLoginInitialContextFactory.java
Sending        security/src/main/org/jboss/security/jndi/SecurityAssociationActions.java
Transmitting file data ..
Committed revision 90097.


> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 11:44:57 2009
From: jira-events at lists.jboss.org (Victor Starenky (JIRA))
Date: Thu, 11 Jun 2009 11:44:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <22303782.1244735097326.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471711#action_12471711 ] 

Victor Starenky commented on JBMESSAGING-1631:
----------------------------------------------

Messages are sent intermittently, there isn't a huge stream of these. But AllMessageCount is in the order of thousands and only increases with every new message. 

What happens with topics is that some node stops receiving messages. It shows all SubscriptionCounts = 0. Once it gets into this state is stays there.

We created our own monitoring system that records every sent message and every received message into database stamped with the time and machine name. This is how we find these problems.

Also when I was speaking about the load I wasn't talking about JMS load but rather the overall machine load. All servers run a large application that's doing tons of jobs overnight. So this might affect ping timeouts - when machine is too busy to respond in time. This is only a theory though.

> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 11:49:00 2009
From: jira-events at lists.jboss.org (Victor Starenky (JIRA))
Date: Thu, 11 Jun 2009 11:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13658536.1244735340340.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471715#action_12471715 ] 

Victor Starenky commented on JBMESSAGING-1456:
----------------------------------------------

Hate to tell but this might have to be reopened. We've just installed new messaging jar together with remoting 2.2.3 and see one message stuck in delivery on one of the queues

> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 12:13:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 11 Jun 2009 12:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1841) Improve logging
 for InterceptorsFactory warning
In-Reply-To: <17265944.1243955516468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16564640.1244736836641.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1841:
-----------------------------------

    Affects Version/s: 1.1.6
                           (was: AS 5.0.0.CR1)


> Improve logging for InterceptorsFactory warning
> -----------------------------------------------
>
>                 Key: EJBTHREE-1841
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1841
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: 1.1.6
>         Environment: Windows XP 32-bit, JBoss AS 5.1.0GA
>            Reporter: Ben Abernathy
>            Assignee: jaikiran pai
>
> Every time this section of code is called, the following warning is displayed:
> 09:02:34,655 WARN  [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
> Upon inspecting EJBTHREE-1246, it appears this warning can be ignored by bean developers. If that is the case, is it necessary to fill up the console and log with benign warnings? There can be lots of these if the application is large.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 12:15:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 11 Jun 2009 12:15:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1841) Improve logging
 for InterceptorsFactory warning
In-Reply-To: <17265944.1243955516468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16908474.1244736956593.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1841.
------------------------------------

    Fix Version/s: 1.1.7
       Resolution: Done


Done. The InterceptorsFactory will no longer be used in the core (ejb3-interceptors-aop.xml). 

> Improve logging for InterceptorsFactory warning
> -----------------------------------------------
>
>                 Key: EJBTHREE-1841
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1841
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: 1.1.6
>         Environment: Windows XP 32-bit, JBoss AS 5.1.0GA
>            Reporter: Ben Abernathy
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> Every time this section of code is called, the following warning is displayed:
> 09:02:34,655 WARN  [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
> Upon inspecting EJBTHREE-1246, it appears this warning can be ignored by bean developers. If that is the case, is it necessary to fill up the console and log with benign warnings? There can be lots of these if the application is large.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 12:28:58 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 11 Jun 2009 12:28:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17973080.1244737738730.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471726#action_12471726 ] 

Howard Gao commented on JBMESSAGING-1456:
-----------------------------------------

Hi Vitor, 

did you use the new parameters in the remoting config file? 
               <attribute name="failureDisconnectTimeout" isParam="true">0</attribute>
               <attribute name="callbackErrorsAllowed">1</attribute>
               <attribute name="useClientConnectionIdentity" isParam="true">true</attribute>

If you are seeing stuck messages, can you try the messaging jars included in test-1456-jars.zip and upload the logs? The logs can give us a proof of whether the message is stuck for the same reason. Thanks.

Howard


> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 12:32:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 11 Jun 2009 12:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-192) Fix interaction
 between metadata and synch checker
Message-ID: <23074204.1244737976457.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix interaction between metadata and synch checker
--------------------------------------------------

                 Key: JBDEPLOY-192
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-192
             Project: JBoss Deployers
          Issue Type: Bug
          Components: structure
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA


Currently metadata checker is picking up leaves from synch checker.
It should only pick up the same leaves from structure cache as restricted by VFS filter.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 12:50:58 2009
From: jira-events at lists.jboss.org (Victor Starenky (JIRA))
Date: Thu, 11 Jun 2009 12:50:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16885649.1244739058474.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471732#action_12471732 ] 

Victor Starenky commented on JBMESSAGING-1456:
----------------------------------------------

Hi Howard,

Yes, we're using the new parameters.
We can't really use the test jars with logging since last time they seemed to cause memory leaks and servers repeatedly ran out of memory.

> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 13:11:56 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 11 Jun 2009 13:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMDR-57) Make MethodSignature
 and DeclaredMethodSignature interchangable in equals and hashCode
Message-ID: <20687081.1244740316458.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make MethodSignature and DeclaredMethodSignature interchangable in equals and hashCode
--------------------------------------------------------------------------------------

                 Key: JBMDR-57
                 URL: https://jira.jboss.org/jira/browse/JBMDR-57
             Project: JBoss MetaData Repository
          Issue Type: Feature Request
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: JBossMDR-2.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 13:11:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 11 Jun 2009 13:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBWEB-144) JSP EL ternary
 operator requires space before colon
Message-ID: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>

JSP EL ternary operator requires space before colon
---------------------------------------------------

                 Key: JBWEB-144
                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossWeb-2.0.0.GA_CP09
            Reporter: Mike Millson
            Assignee: Remy Maucherat


JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:

<c:set var="truevalue" value="true" />
<c:set var="falsevalue" value="false"/>
<c:out value="${not empty param.yes?truevalue:falsevalue}"/>

It throws this error:
2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
       at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)

But this works with a space added before the colon:
<c:out value="${not empty param.yes?truevalue :falsevalue}"/>

This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.

[1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
[2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
[3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 13:16:57 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 11 Jun 2009 13:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMDR-57) Make MethodSignature
 and DeclaredMethodSignature interchangable in equals and hashCode
In-Reply-To: <20687081.1244740316458.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20432074.1244740617146.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMDR-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed JBMDR-57.
---------------------------

    Resolution: Done


> Make MethodSignature and DeclaredMethodSignature interchangable in equals and hashCode
> --------------------------------------------------------------------------------------
>
>                 Key: JBMDR-57
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-57
>             Project: JBoss MetaData Repository
>          Issue Type: Feature Request
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: JBossMDR-2.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 13:20:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 11 Jun 2009 13:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4264874.1244740856550.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-144:
-------------------------------

    Attachment: test.jsp


Reproducer.

> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 13:33:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 11 Jun 2009 13:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24689865.1244741636486.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-144:
-------------------------------

    Component/s: Tomcat


> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 14:02:07 2009
From: jira-events at lists.jboss.org (Zachary Bedell (JIRA))
Date: Thu, 11 Jun 2009 14:02:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-207)
 NullPointerException during
 deployment of EJB3 methods with zero parameters
In-Reply-To: <31747213.1244728808387.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1356284.1244743327357.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Zachary Bedell updated JBMETA-207:
----------------------------------

    Attachment: fixJBMETA207.patch


Fixes this NPE allowing deployment to proceed

> NullPointerException during deployment of EJB3 methods with zero parameters
> ---------------------------------------------------------------------------
>
>                 Key: JBMETA-207
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-207
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.0.GA
>         Environment: JBoss-5.1.0-GA, JDK 1.6.0_07-b06-153 (Apple/Sun JVM, 64-bit on OS/X), EJB3 w/ descriptor overrides
>            Reporter: Zachary Bedell
>            Assignee: Andrew Lee Rubinger
>         Attachments: fixJBMETA207.patch
>
>
> Deploying an EJB3 based EAR results in an NPE with the below stack trace.  The problem appears to manifest with EJB3's containing methods that take zero arguments.  There are also XML descriptor based attributes for several of the metadata elements.  To the best of my knowledge the descriptors only augment, not override anything specified in annotations.
> Patch for this should be trivial (an additional null check on line 83 of RolesAllowedProcessor.java should do it).  I'm in the process of attempting to get JBMETA built from source and integrated into my stack.  Will attach patch & tests unless someone beats me to it.
> The stack:
> 09:44:51,219 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=vfszip:/jboss/jboss-eap-5.0/server/ucmsfc/deploy/ucms.ear/ state=ClassLoader mode=Manual requiredState=PostClassLoader
> org.jboss.deployers.spi.DeploymentException: Cannot process metadata
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:181)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:93)
> 	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.install(DeployersImpl.java:1098)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:698)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:59)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:355)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:310)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:241)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 	at org.jboss.Main.boot(Main.java:216)
> 	at org.jboss.Main$1.run(Main.java:546)
> 	at java.lang.Thread.run(Thread.java:637)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:83)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:48)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:215)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:172)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:151)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:94)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:52)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.process(AbstractCreator.java:154)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.processMetaData(AbstractCreator.java:87)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator.create(JBoss50Creator.java:109)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processJBossMetaData(OptAnnotationMetaDataDeployer.java:134)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processMetaData(OptAnnotationMetaDataDeployer.java:84)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:177)
> 	... 31 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 14:03:56 2009
From: jira-events at lists.jboss.org (Zachary Bedell (JIRA))
Date: Thu, 11 Jun 2009 14:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-207)
 NullPointerException during
 deployment of EJB3 methods with zero parameters
In-Reply-To: <31747213.1244728808387.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7963740.1244743436555.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471762#action_12471762 ] 

Zachary Bedell commented on JBMETA-207:
---------------------------------------

Attached patch fixes this allowing deployment to proceed.  All other unit tests complete successfully with this patch applied.  I'm still having trouble isolating this to fail independent of the rest of JBoss.  I suspect the processing of XML descriptors contributes to the problem.  I'll give it a bit more time before I give up, but unfortunately the object tree for this is a bit above my head at the moment.

> NullPointerException during deployment of EJB3 methods with zero parameters
> ---------------------------------------------------------------------------
>
>                 Key: JBMETA-207
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-207
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.0.GA
>         Environment: JBoss-5.1.0-GA, JDK 1.6.0_07-b06-153 (Apple/Sun JVM, 64-bit on OS/X), EJB3 w/ descriptor overrides
>            Reporter: Zachary Bedell
>            Assignee: Andrew Lee Rubinger
>         Attachments: fixJBMETA207.patch
>
>
> Deploying an EJB3 based EAR results in an NPE with the below stack trace.  The problem appears to manifest with EJB3's containing methods that take zero arguments.  There are also XML descriptor based attributes for several of the metadata elements.  To the best of my knowledge the descriptors only augment, not override anything specified in annotations.
> Patch for this should be trivial (an additional null check on line 83 of RolesAllowedProcessor.java should do it).  I'm in the process of attempting to get JBMETA built from source and integrated into my stack.  Will attach patch & tests unless someone beats me to it.
> The stack:
> 09:44:51,219 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=vfszip:/jboss/jboss-eap-5.0/server/ucmsfc/deploy/ucms.ear/ state=ClassLoader mode=Manual requiredState=PostClassLoader
> org.jboss.deployers.spi.DeploymentException: Cannot process metadata
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:181)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:93)
> 	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.install(DeployersImpl.java:1098)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:698)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:59)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:355)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:310)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:241)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 	at org.jboss.Main.boot(Main.java:216)
> 	at org.jboss.Main$1.run(Main.java:546)
> 	at java.lang.Thread.run(Thread.java:637)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:83)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:48)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:215)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:172)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:151)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:94)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:52)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.process(AbstractCreator.java:154)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.processMetaData(AbstractCreator.java:87)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator.create(JBoss50Creator.java:109)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processJBossMetaData(OptAnnotationMetaDataDeployer.java:134)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processMetaData(OptAnnotationMetaDataDeployer.java:84)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:177)
> 	... 31 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 17:56:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 11 Jun 2009 17:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2119) Support more
 user-friendly time format in timers
Message-ID: <14275268.1244757416414.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support more user-friendly time format in timers
------------------------------------------------

                 Key: JBRULES-2119
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2119
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler (flow), drools-core (flow), drools-eclipse (flow)
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen


Instead of having to specify timer period and delay in milliseconds, we should allow a more user-friendly format like 5s or 3m.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 18:05:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 11 Jun 2009 18:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2120) Dynamic or Ah-Hoc
	node
Message-ID: <13623222.1244757956488.JavaMail.jira@cloud.prod.atl2.jboss.com>

Dynamic or Ah-Hoc node
----------------------

                 Key: JBRULES-2120
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2120
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler (flow), drools-core (flow), drools-eclipse (flow)
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen
             Fix For: FUTURE


An ad-hoc or dynamic node acts as a node container where not all nodes are cleanly connected to each other but they are modeled as separate fragments that are not necessarily linked to each other.  By default, all nodes that do not have an incoming connection would be triggered when the dynamic node is triggered, and the node will wait until all node instances have been completed before continuing.  Different strategies could also allow:
 - (rule or code) constriants that define when certain fragments should be activated
 - the user can add additional node instances at runtime, even though they are not modeled as part of the process, and the node will wait until they are completed as well

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 19:28:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 11 Jun 2009 19:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2121) JavaDialect isn't
 creating unique ids
Message-ID: <30381835.1244762936401.JavaMail.jira@cloud.prod.atl2.jboss.com>

JavaDialect isn't creating unique ids
-------------------------------------

                 Key: JBRULES-2121
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2121
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen
             Fix For: 5.1.0.M1


JavaDialect.getUniqueLegalName(..) should create a new name for a given set of parameters by first checking whether the name already exists in the dialect.
This check was always false as the name it was checking was wrongly constructed.  As a result, duplicate names could be created.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 19:30:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 11 Jun 2009 19:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2121) JavaDialect
 isn't creating unique ids
In-Reply-To: <30381835.1244762936401.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25431041.1244763056460.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen resolved JBRULES-2121.
-------------------------------------

    Resolution: Done


Fixed name that is checked

> JavaDialect isn't creating unique ids
> -------------------------------------
>
>                 Key: JBRULES-2121
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2121
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>            Reporter: Kris Verlaenen
>            Assignee: Kris Verlaenen
>             Fix For: 5.1.0.M1
>
>
> JavaDialect.getUniqueLegalName(..) should create a new name for a given set of parameters by first checking whether the name already exists in the dialect.
> This check was always false as the name it was checking was wrongly constructed.  As a result, duplicate names could be created.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 19:49:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 11 Jun 2009 19:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2119) Support more
 user-friendly time format in timers
In-Reply-To: <14275268.1244757416414.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25006663.1244764196422.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen resolved JBRULES-2119.
-------------------------------------

    Fix Version/s: 5.1.0.M1
       Resolution: Done


Timers now use a String for delay and period

> Support more user-friendly time format in timers
> ------------------------------------------------
>
>                 Key: JBRULES-2119
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2119
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (flow), drools-core (flow), drools-eclipse (flow)
>            Reporter: Kris Verlaenen
>            Assignee: Kris Verlaenen
>             Fix For: 5.1.0.M1
>
>
> Instead of having to specify timer period and delay in milliseconds, we should allow a more user-friendly format like 5s or 3m.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 11 22:48:02 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 11 Jun 2009 22:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28927367.1244774882358.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471799#action_12471799 ] 

Howard Gao commented on JBMESSAGING-1456:
-----------------------------------------

Hi Victor,

You don't need to use the remoting jar in the zip, which may not be up to date and cause the mem leak. You only need to use the jboss-messaging.jar and jboss-messaging-client.jar. These two jars should be the same as CP08 exception those extra logs.

Thanks
Howard


> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 03:07:56 2009
From: jira-events at lists.jboss.org (Toni Rikkola (JIRA))
Date: Fri, 12 Jun 2009 03:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2053) Date management
In-Reply-To: <21303337.1239356723284.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23812996.1244790476933.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toni Rikkola reassigned JBRULES-2053:
-------------------------------------

    Assignee: Toni Rikkola  (was: Mark Proctor)


> Date management
> ---------------
>
>                 Key: JBRULES-2053
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2053
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.0.CR1
>            Reporter: Gilles Hestin
>            Assignee: Toni Rikkola
>             Fix For: 5.1.0.M1
>
>
> Date management :
> 1) Date format :
> The format is dd-MMM-yyyy. We should be able to set a different format as for instance dd/mm/yyyy.
> This property  would be set in a properties file.
> 2) Input field
> No date field available.  Plan to add a date field.
> 3) Error report
> if the user fills a wrong date for instance, a message (dialog box) indicates that the user must have a look at the server log file. It's not user-friendly, and how a business analyst can access to the server (especially if the server is WAS on AIX : access right issue) ?
> The error message should be displayed in the dialog box.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 03:11:56 2009
From: jira-events at lists.jboss.org (Toni Rikkola (JIRA))
Date: Fri, 12 Jun 2009 03:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2053) Date management
In-Reply-To: <21303337.1239356723284.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21471805.1244790716525.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471812#action_12471812 ] 

Toni Rikkola commented on JBRULES-2053:
---------------------------------------

1. and 3. are something that could use the improvements that you are talking about. Not sure how to do 1. without breaking backwards compatibility.

2. Can you describe the situation where you are missing the date picker? Just in case it is something that we have missed.

> Date management
> ---------------
>
>                 Key: JBRULES-2053
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2053
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.0.CR1
>            Reporter: Gilles Hestin
>            Assignee: Toni Rikkola
>             Fix For: 5.1.0.M1
>
>
> Date management :
> 1) Date format :
> The format is dd-MMM-yyyy. We should be able to set a different format as for instance dd/mm/yyyy.
> This property  would be set in a properties file.
> 2) Input field
> No date field available.  Plan to add a date field.
> 3) Error report
> if the user fills a wrong date for instance, a message (dialog box) indicates that the user must have a look at the server log file. It's not user-friendly, and how a business analyst can access to the server (especially if the server is WAS on AIX : access right issue) ?
> The error message should be displayed in the dialog box.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 03:13:56 2009
From: jira-events at lists.jboss.org (Toni Rikkola (JIRA))
Date: Fri, 12 Jun 2009 03:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2109) Upload of
 Resource to Guvnor
 with multiple "." in file name causes resource type identification issues
In-Reply-To: <20350008.1244124897030.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16926656.1244790836573.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toni Rikkola reassigned JBRULES-2109:
-------------------------------------

    Assignee: Toni Rikkola  (was: Mark Proctor)


> Upload of Resource to Guvnor with multiple "." in file name causes resource type identification issues
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2109
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2109
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Graham Gear
>            Assignee: Toni Rikkola
>            Priority: Minor
>
> It seems the resource type identification is based on the file suffix of the resource being uploaded but matches against the first, not last "." in the filename to determine the suffix. This causes issue if the resource includes multiple "." which is valid under most file systems. It is also common for model JARs to include a version number with an extra ".", eg:
> application-model-1.0.0.jar
> The issue can be reproduced by uploading a model, DRL, RF etc to the Guvnor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 03:13:56 2009
From: jira-events at lists.jboss.org (Toni Rikkola (JIRA))
Date: Fri, 12 Jun 2009 03:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2110) Upload of
 RuleFlow with ".rf"
 suffix to Guvnor through WebDAV does not get correctly identified as a
 RuleFlow
In-Reply-To: <21846412.1244125437026.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3315942.1244790836778.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toni Rikkola reassigned JBRULES-2110:
-------------------------------------

    Assignee: Toni Rikkola  (was: Mark Proctor)


> Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2110
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2110
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Graham Gear
>            Assignee: Toni Rikkola
>
> Upload of RuleFlow with ".rf" suffix to Guvnor through WebDAV does not get correctly identified as a RuleFlow.
> To reproduce, add a *.rf resource through JBoss Dev Studio or WebDAV client (eg cadaver) and see the resource get itemised incorrectly as a *.drl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 03:22:56 2009
From: jira-events at lists.jboss.org (Toni Rikkola (JIRA))
Date: Fri, 12 Jun 2009 03:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1992)
 IllegalArgumetException when using @timestamp?
In-Reply-To: <1359404.1236299422577.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26304875.1244791376750.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471815#action_12471815 ] 

Toni Rikkola commented on JBRULES-1992:
---------------------------------------

I doubt that there is any documentation about it. If you want to take a look at this yourself here is the trunk and build instructions:

http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/

https://www.jboss.org/community/wiki/RulesRepositoryBuildInstructions



> IllegalArgumetException when using @timestamp?
> ----------------------------------------------
>
>                 Key: JBRULES-1992
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1992
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (fusion), drools-core (fusion), drools-guvnor
>    Affects Versions: 5.0.0.M5, 5.0.0.CR1
>         Environment: jdk 1.6
>            Reporter: Zoltan Farkas
>            Assignee: Toni Rikkola
>             Fix For: 5.1.0.M1
>
>
> I think problem is with @timestamp, I use GUVNOR to build my package.
> Here is the exception:
> 2009-03-05 19:56:07,891 [http-0.0.0.0-8080-2] ERROR STDERR - com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract org.drools.guvnor.client.rpc.BuilderResult[] org.drools.guvnor
> .client.rpc.RepositoryService.buildPackage(java.lang.String,java.lang.String,boolean) throws com.google.gwt.user.client.rpc.SerializableException' threw an unexpected exception: org.drools.RuntimeDroolsExcep
> tion: java.lang.IllegalArgumentException: argument type mismatch
> 2009-03-05 19:56:07,895 [http-0.0.0.0-8080-2] ERROR STDERR -    at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:360)
> 2009-03-05 19:56:07,895 [http-0.0.0.0-8080-2] ERROR STDERR -    at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:546)
> 2009-03-05 19:56:07,895 [http-0.0.0.0-8080-2] ERROR STDERR -    at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:164)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:86)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.web.ContextFilter$1.process(ContextFilter.java:42)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:53)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.web.ContextFilter.doFilter(ContextFilter.java:37)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 2009-03-05 19:56:07,896 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
> 2009-03-05 19:56:07,897 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 2009-03-05 19:56:07,898 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
> 2009-03-05 19:56:07,898 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> 2009-03-05 19:56:07,898 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> 2009-03-05 19:56:07,898 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
> 2009-03-05 19:56:07,898 [http-0.0.0.0-8080-2] ERROR STDERR -    at java.lang.Thread.run(Thread.java:619)
> 2009-03-05 19:56:07,898 [http-0.0.0.0-8080-2] ERROR STDERR - Caused by: org.drools.RuntimeDroolsException: java.lang.IllegalArgumentException: argument type mismatch
> 2009-03-05 19:56:07,898 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.base.ClassFieldAccessorFactory.getClassFieldReader(ClassFieldAccessorFactory.java:152)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.base.ClassFieldAccessorCache$CacheEntry.getReadAccessor(ClassFieldAccessorCache.java:315)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.base.ClassFieldAccessorCache.getReadAcessor(ClassFieldAccessorCache.java:245)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.base.ClassFieldAccessorStore.wire(ClassFieldAccessorStore.java:379)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.base.ClassFieldAccessorStore.getReader(ClassFieldAccessorStore.java:97)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.base.ClassFieldAccessorStore.getReader(ClassFieldAccessorStore.java:74)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.compiler.PackageBuilder.processTypeDeclarations(PackageBuilder.java:1031)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.compiler.PackageBuilder.mergePackage(PackageBuilder.java:916)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:608)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:284)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.contenthandler.DRLFileContentHandler.compile(DRLFileContentHandler.java:36)
> 2009-03-05 19:56:07,899 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.builder.ContentPackageAssembler.buildAsset(ContentPackageAssembler.java:198)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.builder.ContentPackageAssembler.buildPackage(ContentPackageAssembler.java:178)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.builder.ContentPackageAssembler.<init>(ContentPackageAssembler.java:104)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.builder.ContentPackageAssembler.<init>(ContentPackageAssembler.java:117)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.ServiceImplementation.buildPackage(ServiceImplementation.java:1375)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.ServiceImplementation.buildPackage(ServiceImplementation.java:1359)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at java.lang.reflect.Method.invoke(Method.java:597)
> 2009-03-05 19:56:07,900 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.security.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:157)
> 2009-03-05 19:56:07,901 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.ServiceImplementation_$$_javassist_7.buildPackage(ServiceImplementation_$$_javassist_7.java)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.guvnor.server.RepositoryServiceServlet.buildPackage(RepositoryServiceServlet.java:196)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at java.lang.reflect.Method.invoke(Method.java:597)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:527)
> 2009-03-05 19:56:07,902 [http-0.0.0.0-8080-2] ERROR STDERR -    ... 27 more
> 2009-03-05 19:56:07,903 [http-0.0.0.0-8080-2] ERROR STDERR - Caused by: java.lang.IllegalArgumentException: argument type mismatch
> 2009-03-05 19:56:07,903 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 2009-03-05 19:56:07,903 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> 2009-03-05 19:56:07,903 [http-0.0.0.0-8080-2] ERROR STDERR -    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> 2009-03-05 19:56:07,903 [http-0.0.0.0-8080-2] ERROR STDERR -    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> 2009-03-05 19:56:07,903 [http-0.0.0.0-8080-2] ERROR STDERR -    at org.drools.base.ClassFieldAccessorFactory.getClassFieldReader(ClassFieldAccessorFactory.java:143)
> 2009-03-05 19:56:07,903 [http-0.0.0.0-8080-2] ERROR STDERR -    ... 68 more
> here is my drl:
> package eventprocessor
> import eventprocessor.model.NetworkEvent
> global EventExpertProcessor processor
> declare NetworkEvent
>   	@role( event )
>   	@timestamp( creationTime )
> end
> here is the NetworkEvent code:
> package  eventprocessor.model;
> import java.util.Date;
> /**
>  *
>  * @author zoly
>  */
> public class NetworkEvent {
> 	private String id;
> 	private String description;
> 	private NetworkNode sourceComponent;
> 	private Integer severity;
> 	private Date creationTime;
>     private java.math.BigDecimal locElevation;
>     private java.math.BigDecimal locLongitude;
>     private java.math.BigDecimal locLatitude;
>     /**
>      * @return the id
>      */
>     public String getId()
>     {
>         return id;
>     }
>     /**
>      * @param id the id to set
>      */
>     public void setId(String id)
>     {
>         this.id = id;
>     }
>     /**
>      * @return the description
>      */
>     public String getDescription()
>     {
>         return description;
>     }
>     /**
>      * @param description the description to set
>      */
>     public void setDescription(String description)
>     {
>         this.description = description;
>     }
>     /**
>      * @return the sourceComponent
>      */
>     public NetworkNode getSourceComponent()
>     {
>         return sourceComponent;
>     }
>     /**
>      * @param sourceComponent the sourceComponent to set
>      */
>     public void setSourceComponent(NetworkNode sourceComponent)
>     {
>         this.sourceComponent = sourceComponent;
>     }
>     /**
>      * @return the severity
>      */
>     public Integer getSeverity()
>     {
>         return severity;
>     }
>     /**
>      * @param severity the severity to set
>      */
>     public void setSeverity(Integer severity)
>     {
>         this.severity = severity;
>     }
>     /**
>      * @return the creationTime
>      */
>     public Date getCreationTime()
>     {
>         return creationTime;
>     }
>     /**
>      * @param creationTime the creationTime to set
>      */
>     public void setCreationTime(Date creationTime)
>     {
>         this.creationTime = creationTime;
>     }
>     /**
>      * @return the locElevation
>      */
>     public java.math.BigDecimal getLocElevation()
>     {
>         return locElevation;
>     }
>     /**
>      * @param locElevation the locElevation to set
>      */
>     public void setLocElevation(java.math.BigDecimal locElevation)
>     {
>         this.locElevation = locElevation;
>     }
>     /**
>      * @return the locLongitude
>      */
>     public java.math.BigDecimal getLocLongitude()
>     {
>         return locLongitude;
>     }
>     /**
>      * @param locLongitude the locLongitude to set
>      */
>     public void setLocLongitude(java.math.BigDecimal locLongitude)
>     {
>         this.locLongitude = locLongitude;
>     }
>     /**
>      * @return the locLatitude
>      */
>     public java.math.BigDecimal getLocLatitude()
>     {
>         return locLatitude;
>     }
>     /**
>      * @param locLatitude the locLatitude to set
>      */
>     public void setLocLatitude(java.math.BigDecimal locLatitude)
>     {
>         this.locLatitude = locLatitude;
>     }
>     @Override
>     public boolean equals(Object obj)
>     {
>         if (obj == null)
>         {
>             return false;
>         }
>         if (getClass() != obj.getClass())
>         {
>             return false;
>         }
>         final NetworkEvent other = (NetworkEvent) obj;
>         if ((this.id == null) ? (other.id != null) : !this.id.equals(other.id))
>         {
>             return false;
>         }
>         return true;
>     }
>     @Override
>     public int hashCode()
>     {
>         int hash = 7;
>         hash = 17 * hash + (this.id != null ? this.id.hashCode() : 0);
>         return hash;
>     }
>     public String toString()
>     {
>         StringBuilder toStringBuilder = new StringBuilder();
>         toStringBuilder.append(super.toString());
>         toStringBuilder.append("\n");
>         toStringBuilder.append("\nid: ");
>         toStringBuilder.append(id);
>         toStringBuilder.append("\ndescription: ");
>         toStringBuilder.append(description);
>         toStringBuilder.append("\nsourceComponent: ");
>         toStringBuilder.append(sourceComponent);
>         toStringBuilder.append("\nseverity: ");
>         toStringBuilder.append(severity);
>         toStringBuilder.append("\ncreationTime: ");
>         toStringBuilder.append(creationTime);
>         toStringBuilder.append("\nlocElevation: ");
>         toStringBuilder.append(locElevation);
>         toStringBuilder.append("\nlocLongitude: ");
>         toStringBuilder.append(locLongitude);
>         toStringBuilder.append("\nlocLatitude: ");
>         toStringBuilder.append(locLatitude);
>         return toStringBuilder.toString();
>     }
>     
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 03:49:57 2009
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 12 Jun 2009 03:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-2421) tomahawk
 doesn't see users's roles
In-Reply-To: <31888261.1244644076879.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25769179.1244792997320.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Heute resolved JBPORTAL-2421.
------------------------------------

    Resolution: Rejected


> tomahawk doesn't see users's roles
> ----------------------------------
>
>                 Key: JBPORTAL-2421
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2421
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Security
>    Affects Versions: 2.7.2 Final
>            Reporter: Penkov Vladimir
>
> Create user, give him 'User' role. 
> Create jsf portlet with jsfbridge. Add to some page:
> <t:commandLink ... enabledOnUserRole="User">
> Authenticate as created user. Visit this page. Link will always be disabled.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 04:30:58 2009
From: jira-events at lists.jboss.org (Daan Van Heghe (JIRA))
Date: Fri, 12 Jun 2009 04:30:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6549) Investigate
 increased memory requirements and deployment time
In-Reply-To: <5128231.1235670884495.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28847753.1244795458895.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471842#action_12471842 ] 

Daan Van Heghe commented on JBAS-6549:
--------------------------------------

I have the exact same problems as : 150 EJBs, 1.8Gb virtual memory used (on WindowsXP), startup time 3m30'
I used 4.0.5 before : 800Mb VM used, startup time 1m15'


> Investigate increased memory requirements and deployment time
> -------------------------------------------------------------
>
>                 Key: JBAS-6549
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6549
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.0.GA, JBossAS-5.0.1.GA
>            Reporter: Dimitris Andreadis
>            Assignee: Ales Justin
>         Attachments: AS 5_x profiler snapshot.zip
>
>
> A user reported x2 increase in deployment time and x4 increase in memory usage when moving an application from JBoss 4.2 -> 5.x.
> We need to investigate how to improve both the memory usage and the deployment time.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 04:38:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 04:38:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1848) Remove
 INFO-level logging in EndpointDeployer
In-Reply-To: <23793204.1244795937434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16444970.1244795937586.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1848.
-------------------------------------------

    Resolution: Done


> Remove INFO-level logging in EndpointDeployer
> ---------------------------------------------
>
>                 Key: EJBTHREE-1848
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1848
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: endpoint-deployers
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.7
>
>
> This should go to DEBUG:
> 23:18:05,567 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 6687ec13{name=jboss.j2ee:jar=p
> rofileservice-secured.jar,name=SecureDeploymentManager,service=EJB3_endpoint bean=org.jboss.ejb3.end
> point.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
> ..as to not spam the console.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 04:38:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 04:38:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1848) Remove
 INFO-level logging in EndpointDeployer
Message-ID: <23793204.1244795937434.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remove INFO-level logging in EndpointDeployer
---------------------------------------------

                 Key: EJBTHREE-1848
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1848
             Project: EJB 3.0
          Issue Type: Task
          Components: endpoint-deployers
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.1.7


This should go to DEBUG:

23:18:05,567 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 6687ec13{name=jboss.j2ee:jar=p
rofileservice-secured.jar,name=SecureDeploymentManager,service=EJB3_endpoint bean=org.jboss.ejb3.end
point.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}

..as to not spam the console.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 04:43:08 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 04:43:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1849) Update
 dependency chain for Plugin 1.1.7 Release
Message-ID: <17075972.1244796188455.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update dependency chain for Plugin 1.1.7 Release
------------------------------------------------

                 Key: EJBTHREE-1849
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1849
             Project: EJB 3.0
          Issue Type: Task
            Reporter: Andrew Lee Rubinger
            Assignee: jaikiran pai
             Fix For: 1.1.7


Container task to track commits to update the dependency chain for the EJB3 Plugin 1.1.7 release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 04:48:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 12 Jun 2009 04:48:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1849) Update
 dependency chain for Plugin 1.0.9 Release
In-Reply-To: <17075972.1244796188455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10905289.1244796537075.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1849:
-----------------------------------

        Summary: Update dependency chain for Plugin 1.0.9 Release  (was: Update dependency chain for Plugin 1.1.7 Release)
    Description: Container task to track commits to update the dependency chain for the EJB3 Plugin 1.0.9 release  (was: Container task to track commits to update the dependency chain for the EJB3 Plugin 1.1.7 release)


> Update dependency chain for Plugin 1.0.9 Release
> ------------------------------------------------
>
>                 Key: EJBTHREE-1849
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1849
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Andrew Lee Rubinger
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> Container task to track commits to update the dependency chain for the EJB3 Plugin 1.0.9 release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 05:07:56 2009
From: jira-events at lists.jboss.org (Fred Bricon (JIRA))
Date: Fri, 12 Jun 2009 05:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6870) Error deploying
 JavaEE application which uses Ehcache
In-Reply-To: <25356047.1241615736766.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25758494.1244797676900.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471858#action_12471858 ] 

Fred Bricon commented on JBAS-6870:
-----------------------------------

Hi,

this issue is dicussed [here|http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4194999#4194999]. Basically the persistence name scheme has changed between JBoss AS 4.x and 5.x, and is incompatible with ehCache.

Any workaround advised? (write a custom CacheProvider, use another caching technology)
I can't imagine noone is using AS 5 in combination ehcache w/ hibernate

regards,

Fred Bricon

> Error deploying JavaEE application which uses Ehcache
> -----------------------------------------------------
>
>                 Key: JBAS-6870
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6870
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: JDK 1.5.0_11
> JBoss AS 5.0.1.GA
>            Reporter: Rainer Flicker
>
> Deploying a JavaEE application (EAR), which uses hibernate 3.3.1, JBoss Seam 2.1.1 and Ehcache 1.5.0 results in following error
> (works with JBoss AS 4.2.3.GA):
> 2009-05-06 14:59:14,095 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Start: name=persistence.unit:unitName=asms.ear/asms.jar#asms state=Create
> java.lang.IllegalArgumentException: Cache name cannot contain '/' characters.
> 	at net.sf.ehcache.config.CacheConfiguration.setName(CacheConfiguration.java:163)
> 	at net.sf.ehcache.Cache.setName(Cache.java:1721)
> 	at net.sf.ehcache.CacheManager.addCache(CacheManager.java:632)
> 	at net.sf.ehcache.hibernate.EhCacheProvider.buildCache(EhCacheProvider.java:90)
> 	at org.hibernate.cache.impl.bridge.RegionFactoryCacheProviderBridge.buildEntityRegion(RegionFactoryCacheProviderBridge.java:96)
> 	at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:255)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1327)
> 	at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:867)
> 	at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:669)
> 	at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:132)
> 	at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:301)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
> 	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:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:698)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
> 	at org.jboss.Main.boot(Main.java:209)
> 	at org.jboss.Main$1.run(Main.java:547)
> 	at java.lang.Thread.run(Thread.java:595)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 05:43:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 12 Jun 2009 05:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1841) Improve logging
 for InterceptorsFactory warning
In-Reply-To: <17265944.1243955516468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21509221.1244799836583.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1841:
-----------------------------------

    Component/s: core


> Improve logging for InterceptorsFactory warning
> -----------------------------------------------
>
>                 Key: EJBTHREE-1841
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1841
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core
>    Affects Versions: 1.1.6
>         Environment: Windows XP 32-bit, JBoss AS 5.1.0GA
>            Reporter: Ben Abernathy
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> Every time this section of code is called, the following warning is displayed:
> 09:02:34,655 WARN  [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
> Upon inspecting EJBTHREE-1246, it appears this warning can be ignored by bean developers. If that is the case, is it necessary to fill up the console and log with benign warnings? There can be lots of these if the application is large.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 05:43:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 12 Jun 2009 05:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1838) Fix the
	MultipleEarTestCase
In-Reply-To: <29605108.1243237929207.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25231756.1244799836727.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1838:
-----------------------------------

    Component/s: testsuite


> Fix the MultipleEarTestCase
> ---------------------------
>
>                 Key: EJBTHREE-1838
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1838
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: testsuite
>    Affects Versions: 1.1.6
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> The org.jboss.ejb3.test.persistenceunits.unit.MultipleEarTestCase depends on the contents of the error message in the exception stacktrace, to test that the deployment failed because of the expected issue. The error message have been made more user friendly as part of EJBTHREE-1815 which causes this test case to fail. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 05:45:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 12 Jun 2009 05:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1849) Update
 dependency chain for Plugin 1.0.9 Release
In-Reply-To: <17075972.1244796188455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1332401.1244799956543.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1849:
-----------------------------------

    Component/s: plugin


> Update dependency chain for Plugin 1.0.9 Release
> ------------------------------------------------
>
>                 Key: EJBTHREE-1849
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1849
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: plugin
>            Reporter: Andrew Lee Rubinger
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> Container task to track commits to update the dependency chain for the EJB3 Plugin 1.0.9 release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:04:56 2009
From: jira-events at lists.jboss.org (Martin Vecera (JIRA))
Date: Fri, 12 Jun 2009 06:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2122) SchedulerTest too
	impatient
Message-ID: <14208199.1244801096472.JavaMail.jira@cloud.prod.atl2.jboss.com>

SchedulerTest too impatient
---------------------------

                 Key: JBRULES-2122
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2122
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 4.0.7
            Reporter: Martin Vecera
            Assignee: Mark Proctor


On line 184 in org/drools/reteoo/SchedulerTest.java is a sleep for a data structure to get filled. On some machines, the half second sleep is not sufficient and the tast permanently fails with data.size() == 3 instead of 4.

Could the sleep be prolonged at least to one second?

The drawback of this failure is SOA Platform certification on HP-UX IA64. We have to manually edit the sleep and rerun the test. This slows down the QE process.

Actually, I got the problem with https://svn.jboss.org/repos/labs/labs/jbossrules/soa_tags/4.3.0.GA_IR1/ but it would affect more versions than just 4.0.7 IMHO. Could you please edit the "Affects Version/s" field to all potential versions? Many thanks!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:08:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 06:08:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1647) Correct
 system property
 name in JBMBootstrapServer, add setting of property to start script, add
 config dir to stop script.
In-Reply-To: <29497109.1244665316669.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32874824.1244801337104.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1647:
---------------------------------

    Fix Version/s: 2.0.0.beta2
                       (was: 2.0.0)


> Correct system property name in JBMBootstrapServer, add setting of property to start script, add config dir to stop script.
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1647
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1647
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Scott Clasen
>            Assignee: Andy Taylor
>             Fix For: 2.0.0.beta2
>
>
> Line 88 of JBMBootstrapServer  is
> String dirName = System.getProperty("jbm.bootsrap.bin.dir", ".");
> Property should be jbm.bootstrap.bin.dir instead of jbm.bootsrap.bin.dir?
> Also the start and stop scripts in the bin dir should probably work by setting this property based on the config dir you use, so KILL_ME gets touched in the config dir
> So run.sh should set -Djbm.bootstrap.bin.dir=$CONFIG_DIR
> and stop.sh should capture $1 as $CONFIG_DIR and  touch $CONFIG_DIR/KILL_ME
> otherwise if you are running 2 configs out of the same distro...like
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/one &
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/two &
> CURRENT 
> /messaging-2.0.0.BETA1/bin/stop.sh  
>  //-->BRINGS DOWN BOTH SERVERS
> CHANGED
> /messaging-2.0.0.BETA1/bin/stop.sh /path/to/config/one 
> //-->Brings down only server one

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:08:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 06:08:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22761142.1244801337901.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1646:
---------------------------------

    Fix Version/s: 2.0.0.beta2
                       (was: 2.0.0)


> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>         Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>             Fix For: 2.0.0.beta2
>
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:08:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 06:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1647) Correct
 system property
 name in JBMBootstrapServer, add setting of property to start script, add
 config dir to stop script.
In-Reply-To: <29497109.1244665316669.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14377792.1244801336844.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox reopened JBMESSAGING-1647:
----------------------------------



> Correct system property name in JBMBootstrapServer, add setting of property to start script, add config dir to stop script.
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1647
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1647
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Scott Clasen
>            Assignee: Andy Taylor
>             Fix For: 2.0.0.beta2
>
>
> Line 88 of JBMBootstrapServer  is
> String dirName = System.getProperty("jbm.bootsrap.bin.dir", ".");
> Property should be jbm.bootstrap.bin.dir instead of jbm.bootsrap.bin.dir?
> Also the start and stop scripts in the bin dir should probably work by setting this property based on the config dir you use, so KILL_ME gets touched in the config dir
> So run.sh should set -Djbm.bootstrap.bin.dir=$CONFIG_DIR
> and stop.sh should capture $1 as $CONFIG_DIR and  touch $CONFIG_DIR/KILL_ME
> otherwise if you are running 2 configs out of the same distro...like
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/one &
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/two &
> CURRENT 
> /messaging-2.0.0.BETA1/bin/stop.sh  
>  //-->BRINGS DOWN BOTH SERVERS
> CHANGED
> /messaging-2.0.0.BETA1/bin/stop.sh /path/to/config/one 
> //-->Brings down only server one

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:14:56 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 12 Jun 2009 06:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1650) The
 standalone clustered
 config uses property substitution in the beans file
In-Reply-To: <23696594.1244801696672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23297650.1244801696914.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor reassigned JBMESSAGING-1650:
----------------------------------------

    Assignee: Andy Taylor  (was: Tim Fox)


> The standalone clustered config uses property substitution in the beans file
> ----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1650
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1650
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>             Fix For: 2.0.0.beta2
>
>
> The standalone clustered config uses property substitution in the beans file but supplies no defaults. This means that starting the server always falls over

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:16:56 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 12 Jun 2009 06:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1651) the standalone
 server
 creates the logs and data dir in the bin dir. this should be in the root
 dir
In-Reply-To: <25796726.1244801816594.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23647858.1244801816938.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1651.
------------------------------------

    Resolution: Done


fixed

> the standalone server creates the logs and data dir in the bin dir. this should be in the root dir
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1651
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1651
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>             Fix For: 2.0.0.beta2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:16:56 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 12 Jun 2009 06:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1651) the
 standalone server
 creates the logs and data dir in the bin dir. this should be in the root
 dir
Message-ID: <25796726.1244801816594.JavaMail.jira@cloud.prod.atl2.jboss.com>

the standalone server creates the logs and data dir in the bin dir. this should be in the root dir
--------------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1651
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1651
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0 Beta1
            Reporter: Andy Taylor
            Assignee: Andy Taylor
             Fix For: 2.0.0.beta2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:20:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 06:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1647) Correct system
 property
 name in JBMBootstrapServer, add setting of property to start script, add
 config dir to stop script.
In-Reply-To: <29497109.1244665316669.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32108972.1244802056627.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-1647.
--------------------------------

    Resolution: Done


> Correct system property name in JBMBootstrapServer, add setting of property to start script, add config dir to stop script.
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1647
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1647
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Scott Clasen
>            Assignee: Andy Taylor
>             Fix For: 2.0.0.beta2
>
>
> Line 88 of JBMBootstrapServer  is
> String dirName = System.getProperty("jbm.bootsrap.bin.dir", ".");
> Property should be jbm.bootstrap.bin.dir instead of jbm.bootsrap.bin.dir?
> Also the start and stop scripts in the bin dir should probably work by setting this property based on the config dir you use, so KILL_ME gets touched in the config dir
> So run.sh should set -Djbm.bootstrap.bin.dir=$CONFIG_DIR
> and stop.sh should capture $1 as $CONFIG_DIR and  touch $CONFIG_DIR/KILL_ME
> otherwise if you are running 2 configs out of the same distro...like
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/one &
> /messaging-2.0.0.BETA1/bin/run.sh /path/to/config/two &
> CURRENT 
> /messaging-2.0.0.BETA1/bin/stop.sh  
>  //-->BRINGS DOWN BOTH SERVERS
> CHANGED
> /messaging-2.0.0.BETA1/bin/stop.sh /path/to/config/one 
> //-->Brings down only server one

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:30:56 2009
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 12 Jun 2009 06:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-123) Use QA databases for
 sql scripts creation
In-Reply-To: <4718364.1243587716425.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26997651.1244802656558.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Boleslaw Dawidowicz resolved JBID-123.
--------------------------------------

    Resolution: Done


> Use QA databases for sql scripts creation
> -----------------------------------------
>
>                 Key: JBID-123
>                 URL: https://jira.jboss.org/jira/browse/JBID-123
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Boleslaw Dawidowicz
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.CR1
>
>
> Distro module should use QA databases to generate schema sql scripts instead of local urls. This will let to generate whole range of sql scripts for all currently tested DBs during release process.
> QA database setup is specified in those files:
> http://anonsvn.jboss.org/repos/jbossidentity/idm/tags/1.0.0.Alpha7/idm-testsuite/src/test/resources/datasources/datasources.xml
> http://anonsvn.jboss.org/repos/jbossidentity/idm/tags/1.0.0.Alpha7/idm-testsuite/src/test/resources/datasources/hibernates.xml

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:53:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Fri, 12 Jun 2009 06:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-192) Fix interaction
 between metadata and synch checker
In-Reply-To: <23074204.1244737976457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12340665.1244804036498.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-192.
----------------------------------

    Resolution: Done


Fixed in Deployers trunk.

> Fix interaction between metadata and synch checker
> --------------------------------------------------
>
>                 Key: JBDEPLOY-192
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-192
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: structure
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>
> Currently metadata checker is picking up leaves from synch checker.
> It should only pick up the same leaves from structure cache as restricted by VFS filter.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 07:40:56 2009
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 12 Jun 2009 07:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-97) Test with LDAP servers
 matrix in hudson
In-Reply-To: <27637113.1242040006361.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17207559.1244806856518.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Boleslaw Dawidowicz updated JBID-97:
------------------------------------

    Fix Version/s: idm-1.1.0.Alpha1
                       (was: idm-1.0.0.GA)


> Test with LDAP servers matrix in hudson
> ---------------------------------------
>
>                 Key: JBID-97
>                 URL: https://jira.jboss.org/jira/browse/JBID-97
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Boleslaw Dawidowicz
>            Assignee: Boleslaw Dawidowicz
>             Fix For: idm-1.1.0.Alpha1
>
>
> Automated testing in hudson should be performed against (at least):
> - OpenLDAP
> - OpenDS
> - RedHat Directory Server
> - Sun Directory Server
> - Microsoft Active Directory

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 07:46:56 2009
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 12 Jun 2009 07:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-107) LDAPIdentityStoreImpl
 missing features
In-Reply-To: <26311352.1242125507014.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8187847.1244807216548.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Boleslaw Dawidowicz updated JBID-107:
-------------------------------------

    Fix Version/s: idm-1.1.0.Alpha1
                       (was: idm-1.0.0.CR1)


> LDAPIdentityStoreImpl missing features
> --------------------------------------
>
>                 Key: JBID-107
>                 URL: https://jira.jboss.org/jira/browse/JBID-107
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Boleslaw Dawidowicz
>            Assignee: Boleslaw Dawidowicz
>             Fix For: idm-1.1.0.Alpha1
>
>
> Missing features
> - Use external JNDI
> - Custom pluggable JNDI provider (SPI). Will enable to add small features like connection credentials encoding and etc.
> - Page control (keep cookie with additional query data in session context and pray that following query will fit...)
> - Inverse membership search (using memberOf attribute)
> - Make Search and Page control criticality optional

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 08:19:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 08:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1652) Convert build
 to use Maven repository
Message-ID: <20391798.1244809196438.JavaMail.jira@cloud.prod.atl2.jboss.com>

Convert build to use Maven repository
-------------------------------------

                 Key: JBMESSAGING-1652
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1652
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
            Assignee: Tim Fox
             Fix For: 2.0.0


We should convert the build to use the Maven repository and Maven dependency checking rather than the old JBoss Repository.

The rest of the build can stay with ant.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 08:31:56 2009
From: jira-events at lists.jboss.org (Dave Lindquist (JIRA))
Date: Fri, 12 Jun 2009 08:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-5980)
 DeploymentException: No
 Attribute found with name: PolicyConfigurationFacadeMBean
In-Reply-To: <29599323.1222078281210.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23278310.1244809916715.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471893#action_12471893 ] 

Dave Lindquist commented on JBAS-5980:
--------------------------------------

Just to add some follow-up to this item...

I also encountered this problem, trying to move from 4.2.2 to 5.1.0.

The problem was a badly packaged EAR file -- JBoss 5 is not as 'forgiving' as 4 in this respect.

Basically, I had an EAR file that contained an EJB JAR and a WAR.  The packaging errors were:
1. All of the classes (servlet included) were packaged into the JAR, instead of properly dispersed (ie, servlet classes in the WAR).
2. The library JARs made use of were all inside the JAR, instead of inside the lib directory of the EAR.
3. I had no ejb-jar.xml file in the JAR.
(and I believe that there were some other little items as well)

Bottom line is, package the EAR file in a proper and approved fashion, and this problem will go away.


> DeploymentException: No Attribute found with name: PolicyConfigurationFacadeMBean
> ---------------------------------------------------------------------------------
>
>                 Key: JBAS-5980
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5980
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: Windows XP SP2, Sun Java 1.5.0_16-b02, JBossAS-5.0.0.CR2, EJB3, Struts 1.3.8
>            Reporter: Rene Leonhardt
>            Assignee: Ales Justin
>
> I have a Struts 1.3.8 and EJB 3.0 application which works just fine in JBoss 4.2.3 but JBoss 5.0.0.CR2 gives many errors when I deploy the EAR (and make the necessary changes to the default configuration):
> 2008-09-22 11:43:45,546 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) Unable to retrieve orb
> javax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
>     at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:559)
>     at org.jboss.web.tomcat.service.deployers.TomcatDeployment$EncListener.lifecycleEvent(TomcatDeployment.java:508)
> 2008-09-22 11:43:47,265 DEBUG [org.jboss.messaging.core.impl.JDBCSupport] (main) Failed to execute: CREATE TABLE JBM_USER (USER_ID VARCHAR(32) NOT NULL, PASSWD VARCHAR(32) NOT NULL, CLIENTID VARCHAR(128), PRIMARY KEY(USER_ID))
> java.sql.SQLException: Table already exists: JBM_USER in statement [CREATE TABLE JBM_USER]
>     at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
>     at org.hsqldb.jdbc.jdbcStatement.fetchResult(Unknown Source)
>     at org.hsqldb.jdbc.jdbcStatement.executeUpdate(Unknown Source)
>     at org.jboss.resource.adapter.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:249)
>     at org.jboss.messaging.core.impl.JDBCSupport.createSchema(JDBCSupport.java:301)
>     at org.jboss.messaging.core.impl.JDBCSupport.start(JDBCSupport.java:167)
>     at org.jboss.jms.server.plugin.JDBCJMSUserManager.start(JDBCJMSUserManager.java:98)
>     at org.jboss.jms.server.plugin.JDBCJMSUserManagerService.startService(JDBCJMSUserManagerService.java:78)
>     at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
>     at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)
> 2008-09-22 11:43:54,296 INFO  [org.hibernate.connection.ConnectionProviderFactory] (main) Initializing connection provider: org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider
> 2008-09-22 11:43:54,296 INFO  [org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider] (main) Using provided datasource
> 2008-09-22 11:43:54,296 DEBUG [org.jboss.util.NestedThrowable] (main) org.jboss.util.NestedThrowable.parentTraceEnabled=true
> 2008-09-22 11:43:54,296 DEBUG [org.jboss.util.NestedThrowable] (main) org.jboss.util.NestedThrowable.nestedTraceEnabled=false
> 2008-09-22 11:43:54,296 DEBUG [org.jboss.util.NestedThrowable] (main) org.jboss.util.NestedThrowable.detectDuplicateNesting=true
> 2008-09-22 11:43:54,296 WARN  [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] (main) Throwable while attempting to get a new connection: null
> org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (org.jboss.resource.JBossResourceException: Failed to register driver for: oracle.jdbc.driver.OracleDriver; - nested throwable: (java.lang.ClassNotFoundException: oracle.jdbc.driver.OracleDriver from BaseClassLoader at be4d44{VFSClassLoaderPolicy at 1c2df08{name=vfszip:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear domain=ClassLoaderDomain at 14562c5{name=DefaultDomain parentPolicy=BEFORE parent=org.jboss.system.NoAnnotationURLClassLoader at 1e13d52} roots=[MemoryContextHandler at 12618553[path= context=vfsmemory://1l1k2t1k-f8xjnv-flewujwc-1-flewuvyt-1s real=vfsmemory://1l1k2t1k-f8xjnv-flewujwc-1-flewuvyt-1s], DelegatingHandler at 16021684[path=myapplication.ear context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear], DelegatingHandler at 2135767[path=myapplication.ear/myapplication-ejb.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplication-ejb.jar], DelegatingHandler at 26153692[path=myapplication.ear/myapplicationFramework.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplicationFramework.jar], DelegatingHandler at 2050852[path=myapplication.ear/myapplicationVO.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplicationVO.jar], DelegatingHandler at 8271067[path=myapplication.ear/mysql-connector-java-5.1.6-bin.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/mysql-connector-java-5.1.6-bin.jar], DelegatingHandler at 29371829[path=myapplication.ear/tibjms.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/tibjms.jar], DelegatingHandler at 33093423[path=myapplication.ear/jakarta-oro-2.0.8.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/jakarta-oro-2.0.8.jar], DelegatingHandler at 2904191[path=myapplication.ear/castor-1.1.1.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/castor-1.1.1.jar], ZipEntryHandler at 22602435[path=myapplication.ear/myapplication-ejb.jar/config context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplication-ejb.jar/config]]  delegates=null exported=[com.tibco.tibjms.naming, org.exolab.castor.jdo.oql, org.exolab.castor.util.dialog, org.exolab.castor.gui.images, org.exolab.castor.dsml.tools, com.mysql.jdbc, org.castor.persist.resolver, org.exolab.castor.xml.schema.reader, com.mysql.jdbc.util, org.exolab.castor.tools, org.castor.cache.simple, org.exolab.castor, com.mysql.jdbc.log, org.castor.transactionmanager, org.exolab.castor.xml.validators, org.gjt.mm.mysql, org.apache.oro.text.regex, com.tibco.tibjms, org.exolab.castor.types, org.exolab.castor.util.resources, org.castor.jdo.engine, org.apache.oro.util, org.apache.oro.text.perl, org.exolab.castor.dsml.mozilla, org.castor.cache.distributed, org.exolab.castor.xml.schema, com.tibco.tibjms.naming.tibjmsnaming, com.mysql.jdbc.configs, org.exolab.castor.persist, org.exolab.castor.core.exceptions, org.castor.jdo.conf, org.exolab.castor.net.util, org.exolab.castor.jdo.engine, org.exolab.castor.xml.schema.util, org.exolab.castor.mapping.loader, org.castor.util.concurrent, org.exolab.castor.jdo.drivers, org.castor, org.exolab.castor.xml.descriptors, org.exolab.castor.mapping.xml.types, org.exolab.castor.mapping.handlers, org.castor.jdo.util, com.mysql.jdbc.jdbc2.optional, org.exolab.castor.dsml, com.mysql.jdbc.profiler, org.exolab.castor.xml.schema.writer, org.exolab.castor.jdo.keygen, org.exolab.castor.xml.wls8, org.exolab.castor.dsml.jndi, com.mysql.jdbc.exceptions.jdbc4, org.exolab.castor.gui, org.castor.persist.cache, org.exolab.castor.xml.util, org.exolab.castor.util, org.exolab.castor.xml.dtd.parser, META-INF, org.exolab.castor.mapping, org.exolab.castor.xml.location, org.castor.cache.hashbelt, org.apache.oro.text, com.mysql.jdbc.exceptions, org.exolab.castor.xml, META-INF.services, org.exolab.castor.jdo, org.castor.cache.hashbelt.container, org.exolab.castor.persist.spi, org.exolab.castor.dtx, org.exolab.castor.xml.schema.simpletypes, org.castor.persist, org.apache.oro.text.awk, org.apache.oro.io, org.castor.cache, com.mysql.jdbc.integration.jboss, org.exolab.castor.xml.schema.simpletypes.factory, org.exolab.castor.xml.handlers, org.castor.jdo.drivers, org.exolab.castor.xml.dtd, com.mysql.jdbc.integration.c3p0, org.exolab.castor.net, org.castor.util, org.castor.cache.hashbelt.reaper, org.exolab.castor.dsml.schema, org.castor.mapping, org.castor.persist.proxy, org.exolab.castor.mapping.xml, com.mysql.jdbc.interceptors, ] <IMPORT-ALL>NON_EMPTY}}))
>     at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:225)
>     at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:195)
>     at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:611)
>     at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:257)
>     at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:607)
>     at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:354)
>     at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:381)
>     at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:409)
>     at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:854)
>     at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
>     at org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.getConnection(InjectedDataSourceConnectionProvider.java:46)
>     at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:111)
>     at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2101)
>     at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1325)
>     at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:867)
>     at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:669)
>     at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:132)
>     at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:281)
> Caused by: java.lang.ClassNotFoundException: oracle.jdbc.driver.OracleDriver from BaseClassLoader at be4d44{VFSClassLoaderPolicy at 1c2df08{name=vfszip:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear domain=ClassLoaderDomain at 14562c5{name=DefaultDomain parentPolicy=BEFORE parent=org.jboss.system.NoAnnotationURLClassLoader at 1e13d52} roots=[MemoryContextHandler at 12618553[path= context=vfsmemory://1l1k2t1k-f8xjnv-flewujwc-1-flewuvyt-1s real=vfsmemory://1l1k2t1k-f8xjnv-flewujwc-1-flewuvyt-1s], DelegatingHandler at 16021684[path=myapplication.ear context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear], DelegatingHandler at 2135767[path=myapplication.ear/myapplication-ejb.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplication-ejb.jar], DelegatingHandler at 26153692[path=myapplication.ear/myapplicationFramework.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplicationFramework.jar], DelegatingHandler at 2050852[path=myapplication.ear/myapplicationVO.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplicationVO.jar], DelegatingHandler at 8271067[path=myapplication.ear/mysql-connector-java-5.1.6-bin.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/mysql-connector-java-5.1.6-bin.jar], DelegatingHandler at 29371829[path=myapplication.ear/tibjms.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/tibjms.jar], DelegatingHandler at 33093423[path=myapplication.ear/jakarta-oro-2.0.8.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/jakarta-oro-2.0.8.jar], DelegatingHandler at 2904191[path=myapplication.ear/castor-1.1.1.jar context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/castor-1.1.1.jar], ZipEntryHandler at 22602435[path=myapplication.ear/myapplication-ejb.jar/config context=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/ real=file:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplication-ejb.jar/config]]  delegates=null exported=[com.tibco.tibjms.naming, org.exolab.castor.jdo.oql, org.exolab.castor.util.dialog, org.exolab.castor.gui.images, org.exolab.castor.dsml.tools, com.mysql.jdbc, org.castor.persist.resolver, org.exolab.castor.xml.schema.reader, com.mysql.jdbc.util, org.exolab.castor.tools, org.castor.cache.simple, org.exolab.castor, com.mysql.jdbc.log, org.castor.transactionmanager, org.exolab.castor.xml.validators, org.gjt.mm.mysql, org.apache.oro.text.regex, com.tibco.tibjms, org.exolab.castor.types, org.exolab.castor.util.resources, org.castor.jdo.engine, org.apache.oro.util, org.apache.oro.text.perl, org.exolab.castor.dsml.mozilla, org.castor.cache.distributed, org.exolab.castor.xml.schema, com.tibco.tibjms.naming.tibjmsnaming, com.mysql.jdbc.configs, org.exolab.castor.persist, org.exolab.castor.core.exceptions, org.castor.jdo.conf, org.exolab.castor.net.util, org.exolab.castor.jdo.engine, org.exolab.castor.xml.schema.util, org.exolab.castor.mapping.loader, org.castor.util.concurrent, org.exolab.castor.jdo.drivers, org.castor, org.exolab.castor.xml.descriptors, org.exolab.castor.mapping.xml.types, org.exolab.castor.mapping.handlers, org.castor.jdo.util, com.mysql.jdbc.jdbc2.optional, org.exolab.castor.dsml, com.mysql.jdbc.profiler, org.exolab.castor.xml.schema.writer, org.exolab.castor.jdo.keygen, org.exolab.castor.xml.wls8, org.exolab.castor.dsml.jndi, com.mysql.jdbc.exceptions.jdbc4, org.exolab.castor.gui, org.castor.persist.cache, org.exolab.castor.xml.util, org.exolab.castor.util, org.exolab.castor.xml.dtd.parser, META-INF, org.exolab.castor.mapping, org.exolab.castor.xml.location, org.castor.cache.hashbelt, org.apache.oro.text, com.mysql.jdbc.exceptions, org.exolab.castor.xml, META-INF.services, org.exolab.castor.jdo, org.castor.cache.hashbelt.container, org.exolab.castor.persist.spi, org.exolab.castor.dtx, org.exolab.castor.xml.schema.simpletypes, org.castor.persist, org.apache.oro.text.awk, org.apache.oro.io, org.castor.cache, com.mysql.jdbc.integration.jboss, org.exolab.castor.xml.schema.simpletypes.factory, org.exolab.castor.xml.handlers, org.castor.jdo.drivers, org.exolab.castor.xml.dtd, com.mysql.jdbc.integration.c3p0, org.exolab.castor.net, org.castor.util, org.castor.cache.hashbelt.reaper, org.exolab.castor.dsml.schema, org.castor.mapping, org.castor.persist.proxy, org.exolab.castor.mapping.xml, com.mysql.jdbc.interceptors, ] <IMPORT-ALL>NON_EMPTY}}
>     at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:381)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>     at java.lang.Class.forName0(Native Method)
>     at java.lang.Class.forName(Class.java:242)
>     at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.getDriver(LocalManagedConnectionFactory.java:474)
> 2008-09-22 11:43:56,718 WARN  [org.jboss.wsf.container.jboss50.deployer.JAXWSDeployerHookPreJSE] (main) Cannot load servlet class: org.apache.struts.action.ActionServlet
> 2008-09-22 11:44:03,031 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Configured: name=jboss.jacc:id="vfszip:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplication-ejb.jar",parent="myapplication.ear",service=jacc state=Instantiated mode=Manual requiredState=Configured
> org.jboss.deployment.DeploymentException: No Attribute found with name: PolicyConfigurationFacadeMBean for jboss.jacc:service=jacc,id="vfszip:/C:/Programme/jboss-5.0.0.CR2/server/default/deploy/myapplication.ear/myapplication-ejb.jar",parent="myapplication.ear", attributes: [JaccContextID, PolicyConfiguration]
>     at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:127)
>     at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:99)
>     at org.jboss.system.microcontainer.ConfigureAction.installAction(ConfigureAction.java:58)
>     at org.jboss.system.microcontainer.ConfigureAction.installAction(ConfigureAction.java:42)
>     at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
>     at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
>     at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
>     at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>     at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Fri Jun 12 08:56:57 2009
From: jira-events at lists.jboss.org (Mathiyalagan Gopal (JIRA))
Date: Fri, 12 Jun 2009 08:56:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7011) Jboss high memory
 leak in SMP
 kernel 2.6.9-78.0.13.ELsmp but not in Non-SMP kernel 2.6.9-78.0.13.EL
Message-ID: <25374810.1244811417061.JavaMail.jira@cloud.prod.atl2.jboss.com>

Jboss high memory leak in SMP kernel 2.6.9-78.0.13.ELsmp but not in Non-SMP kernel 2.6.9-78.0.13.EL
---------------------------------------------------------------------------------------------------

                 Key: JBAS-7011
                 URL: https://jira.jboss.org/jira/browse/JBAS-7011
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.0.5.GA
         Environment: HP DL380 G4 with 4 GB RAM and Duel Core CPU with 3.60 GHz, Linux AS 4 64-bit 2.6.9-78.0.13.ELsmp.
            Reporter: Mathiyalagan Gopal
            Priority: Critical


Hello All,
We are the GE AssetIntelligence running our J2EE based web application in the famous combination of apache + Jboss servers. Our site was running now almost 2 yrs...after deep JVM memory investigation I found there is huge memory leak in the SMP kernel Linux Jboss systems. When I switched the same machine to run on Non-SMP kernel (i,e EL rather then ELsmp) the memory management handeled very well.
When we run our Jboss application server in SMP kernel we have to bounce our jboss instance minimum 2 times a day to reset the JVM Heap, but with non-SMP kernel its running fine and we dont have to do anything. Is anybody out here facing the same issue?

Note : For JVM heap diagnosis we used JProbe as well as Java inbuilt "jmap" utility to generate the report every hour for heap size and live objects.


I am running following versions of servers,

Hardware :HP DL 380 G4 ( 4 GB RAM , 2 Duel Core CPU 3.60 GHz)
Server 1 : Apache-2.2.11
Server 2,3 & 4 : Jboss-4.0.5.GA 

Using apache-2.2.x (mod_loadbalancer) module to connect back end servers.

My JAVA_OPTS vales are

 JAVA_OPTS="-Xms3096m -Xmx3096m -XX:MaxPermSize=256m -Djavax.xml.ws.spi.Provider=org.apache.cxf.jaxws.spi.ProviderImpl -Dorg.apache.cxf.bus.factory=org.apache.cxf.bus.CXFBusFactory -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.partition.name=vip-production-lpap03XXXX -Dtsf.environment=PRD -Dnodename=XXXXXXXX"

Any help will be appreciated!!


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 09:36:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 12 Jun 2009 09:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-71) JBoss TS 4.6.1.GA
In-Reply-To: <3458115.1236869844986.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22684036.1244813816455.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-71:
---------------------------------

    Summary: JBoss TS 4.6.1.GA  (was: JBoss TS 4.4.0.GA)


> JBoss TS 4.6.1.GA
> -----------------
>
>                 Key: JBJCA-71
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-71
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha1
>
>
> Standalone + Test

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 09:42:56 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 12 Jun 2009 09:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMICROCONT-445) Make
 'gettingStarted' example work when run with custom classloader
Message-ID: <19601810.1244814176467.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make 'gettingStarted' example work when run with custom classloader
-------------------------------------------------------------------

                 Key: JBMICROCONT-445
                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-445
             Project: JBoss Microcontainer
          Issue Type: Bug
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: JBossMC-2.2.x


https://svn.jboss.org/repos/jbossas/projects/microcontainer/mcdocs/trunk/examples/User_Guide/gettingStarted
$mvn install
$cd commandLineClient
$mvn install
$cd target/client-cl.dir
$./run.sh bus

The Client class references classes such as Employee which are only present in the humanResourcesService-1.0.0.jar which is loaded by another classloader

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 10:41:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 12 Jun 2009 10:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1653) specify the
 management attribute as lower-cased in management messages
Message-ID: <2107452.1244817716743.JavaMail.jira@cloud.prod.atl2.jboss.com>

specify the management attribute as lower-cased in management messages
----------------------------------------------------------------------

                 Key: JBMESSAGING-1653
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1653
             Project: JBoss Messaging
          Issue Type: Task
          Components: Configuration and Management
    Affects Versions: 2.0.0 Beta1
            Reporter: Jeff Mesnil
            Assignee: Tim Fox
            Priority: Minor
             Fix For: 2.0.0


to be more consistent with Java conventions, the user should be able to specify management attribute lower-cased when sending
management message with ManagementHelper.putAttribute() method.
E.g. to retrieve the value of the QueueContrlol's messageCount, the user will call ManagementHelper.putAttribute(msg, res, "messageCount") and no longer  ManagementHelper.putAttribute(msg, res, "MessageCount")

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 11:08:57 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 12 Jun 2009 11:08:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1643868.1244819337237.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned JBAS-6888:
--------------------------------

    Assignee: Flavia Rainone  (was: Kabir Khan)


> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Flavia Rainone
>         Attachments: server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 11:12:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 12 Jun 2009 11:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9832692.1244819576433.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened JBAS-7010:
--------------------------------



Scott, I'm using the latest from the EAP branch and am still getting the "Caller unauthorized" error. The client I'm using is at https://svn.jboss.org/repos/jopr/trunk/etc/jbas5-ejb-client/. Would you please try with my client and see if it fails for you as well, and, if so, see if you can figure out what's wrong.


> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 11:27:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 12 Jun 2009 11:27:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1654) Optimization
 on Journal: Use optimized buffers instead of ByteBuffer
In-Reply-To: <8071800.1244820476823.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4025682.1244820477065.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1654.
----------------------------------------

    Resolution: Done


> Optimization on Journal: Use optimized buffers instead of ByteBuffer
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1654
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1654
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Tim Fox
>             Fix For: 2.0.0.beta2
>
>
> Instead of using ByteBuffer on the journal, we are now using MessagingBuffer (HeapBuffer), and that manages a byte array directly, doing faster copies with System.arrayCopy what is much faster than the way ByteBuffer copies them.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 11:27:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 12 Jun 2009 11:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1654) Optimization
 on Journal: Use optimized buffers instead of ByteBuffer
Message-ID: <8071800.1244820476823.JavaMail.jira@cloud.prod.atl2.jboss.com>

Optimization on Journal: Use optimized buffers instead of ByteBuffer
--------------------------------------------------------------------

                 Key: JBMESSAGING-1654
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1654
             Project: JBoss Messaging
          Issue Type: Feature Request
            Reporter: Clebert Suconic
            Assignee: Tim Fox
             Fix For: 2.0.0.beta2


Instead of using ByteBuffer on the journal, we are now using MessagingBuffer (HeapBuffer), and that manages a byte array directly, doing faster copies with System.arrayCopy what is much faster than the way ByteBuffer copies them.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 11:48:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 12 Jun 2009 11:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-84) Add support for
 hasAnnotation(Class) and getAnnotation(Class)
Message-ID: <11699216.1244821736498.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for hasAnnotation(Class) and getAnnotation(Class)
-------------------------------------------------------------

                 Key: JASSIST-84
                 URL: https://jira.jboss.org/jira/browse/JASSIST-84
             Project: Javassist
          Issue Type: Feature Request
            Reporter: Jesper Pedersen
            Assignee: Shigeru Chiba


It would nice if Javassist had functionality to query 

 boolean hasAnnotation(Class)

and retrieve a single annotation 

 Object getAnnotation(Class)

for CtClass, CtBehavior and CtField.

The attached implements this functionality against CVS HEAD.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 11:50:56 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 12 Jun 2009 11:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-84) Add support for
 hasAnnotation(Class) and getAnnotation(Class)
In-Reply-To: <11699216.1244821736498.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14181594.1244821856950.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JASSIST-84:
-----------------------------------

    Attachment: JASSIST-84.patch


> Add support for hasAnnotation(Class) and getAnnotation(Class)
> -------------------------------------------------------------
>
>                 Key: JASSIST-84
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-84
>             Project: Javassist
>          Issue Type: Feature Request
>            Reporter: Jesper Pedersen
>            Assignee: Shigeru Chiba
>         Attachments: JASSIST-84.patch
>
>
> It would nice if Javassist had functionality to query 
>  boolean hasAnnotation(Class)
> and retrieve a single annotation 
>  Object getAnnotation(Class)
> for CtClass, CtBehavior and CtField.
> The attached implements this functionality against CVS HEAD.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:14:57 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 12 Jun 2009 06:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1650) The standalone
 clustered config uses property substitution in the beans file
In-Reply-To: <23696594.1244801696672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24734032.1244801697115.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1650.
------------------------------------

    Resolution: Done


fixed

> The standalone clustered config uses property substitution in the beans file
> ----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1650
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1650
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>             Fix For: 2.0.0.beta2
>
>
> The standalone clustered config uses property substitution in the beans file but supplies no defaults. This means that starting the server always falls over

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 06:14:56 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 12 Jun 2009 06:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1650) The
 standalone clustered
 config uses property substitution in the beans file
Message-ID: <23696594.1244801696672.JavaMail.jira@cloud.prod.atl2.jboss.com>

The standalone clustered config uses property substitution in the beans file
----------------------------------------------------------------------------

                 Key: JBMESSAGING-1650
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1650
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0 Beta1
            Reporter: Andy Taylor
            Assignee: Tim Fox
             Fix For: 2.0.0.beta2


The standalone clustered config uses property substitution in the beans file but supplies no defaults. This means that starting the server always falls over

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 12:10:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Fri, 12 Jun 2009 12:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Work started: (JBID-71) Automatic
 installation of IDM Component for Hudson Runs
In-Reply-To: <22073830.1237893802542.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8564238.1244823056725.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on JBID-71 started by Jeff Yu.

> Automatic installation of IDM Component for Hudson Runs
> -------------------------------------------------------
>
>                 Key: JBID-71
>                 URL: https://jira.jboss.org/jira/browse/JBID-71
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>    Affects Versions: IDFED-1.0.0.CR1
>            Reporter: Tom Baeyens
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> In jBPM, as part of our hudson runs, we'll need an automatic install of the idm component in JBoss.   The script should take as input the database and a number of jdbc properties.
> Also the DataSource creation should be part of the automatic install.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 12:10:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Fri, 12 Jun 2009 12:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-71) Automatic
 installation of IDM Component for Hudson Runs
In-Reply-To: <22073830.1237893802542.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7226729.1244823056974.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Yu resolved JBID-71.
-------------------------

    Fix Version/s: idm-1.0.0.Beta1
                       (was: idm-1.0.0.GA)
       Resolution: Done


> Automatic installation of IDM Component for Hudson Runs
> -------------------------------------------------------
>
>                 Key: JBID-71
>                 URL: https://jira.jboss.org/jira/browse/JBID-71
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>    Affects Versions: IDFED-1.0.0.CR1
>            Reporter: Tom Baeyens
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> In jBPM, as part of our hudson runs, we'll need an automatic install of the idm component in JBoss.   The script should take as input the database and a number of jdbc properties.
> Also the DataSource creation should be part of the automatic install.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 12:26:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 12 Jun 2009 12:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7012) exclude the
 admin-console from annotation scanning
In-Reply-To: <25457167.1244823656534.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8414446.1244824016598.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved JBAS-7012.
---------------------------------------

    Resolution: Done


> exclude the admin-console from annotation scanning
> --------------------------------------------------
>
>                 Key: JBAS-7012
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7012
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 12:40:59 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 12 Jun 2009 12:40:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17105437.1244824859133.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471954#action_12471954 ] 

Howard Gao commented on JBMESSAGING-1456:
-----------------------------------------

Hi Victor,

the jars in the zip may not contain some other fixes in 1.4.4. But regarding to this fix, they should be the same. I wouldn't suggest you drop them to your production env. If you have a test env, you can try it. 

Or if you can tell me how to reproduce, I'll try myself.

Thanks,
Howard


> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 12:13:03 2009
From: jira-events at lists.jboss.org (Victor Starenky (JIRA))
Date: Fri, 12 Jun 2009 12:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4023589.1244823183072.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471944#action_12471944 ] 

Victor Starenky commented on JBMESSAGING-1456:
----------------------------------------------

But the one we're currently using is 1.4.4
Would it be a safe drop-in replacement?

> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 12:20:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 12 Jun 2009 12:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7012) exclude the
 admin-console from annotation scanning
Message-ID: <25457167.1244823656534.JavaMail.jira@cloud.prod.atl2.jboss.com>

exclude the admin-console from annotation scanning
--------------------------------------------------

                 Key: JBAS-7012
                 URL: https://jira.jboss.org/jira/browse/JBAS-7012
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 13:04:58 2009
From: jira-events at lists.jboss.org (Victor Starenky (JIRA))
Date: Fri, 12 Jun 2009 13:04:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27075283.1244826298433.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471956#action_12471956 ] 

Victor Starenky commented on JBMESSAGING-1456:
----------------------------------------------

well, it's a production environment that is able to reproduce this specific bug more or less reliably. so we'll see if we can put these jars in prod to get some useful logs for both this issue as well as JBMESSAGING-1631 

> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 13:12:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 13:12:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20605984.1244826777312.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-1646.
--------------------------------

    Resolution: Done


> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>         Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>             Fix For: 2.0.0.beta2
>
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 13:12:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 13:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1655) Default
 clustered config is incorrect
Message-ID: <24332670.1244826776782.JavaMail.jira@cloud.prod.atl2.jboss.com>

Default clustered config is incorrect
-------------------------------------

                 Key: JBMESSAGING-1655
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1655
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
            Assignee: Tim Fox
             Fix For: 2.0.0.beta2


Default clustered configs are incorrect - need adjusting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 13:12:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 12 Jun 2009 13:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1655) Default
 clustered config is incorrect
In-Reply-To: <24332670.1244826776782.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1890857.1244826776960.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-1655.
--------------------------------

    Resolution: Done


> Default clustered config is incorrect
> -------------------------------------
>
>                 Key: JBMESSAGING-1655
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1655
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0.beta2
>
>
> Default clustered configs are incorrect - need adjusting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 14:19:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 12 Jun 2009 14:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1849) Update
 dependency chain for Plugin 1.0.9 Release
In-Reply-To: <17075972.1244796188455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30680112.1244830796655.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1849.
------------------------------------

    Resolution: Done


Plugin 1.0.9 has been released

> Update dependency chain for Plugin 1.0.9 Release
> ------------------------------------------------
>
>                 Key: EJBTHREE-1849
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1849
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: plugin
>            Reporter: Andrew Lee Rubinger
>            Assignee: jaikiran pai
>             Fix For: 1.1.7
>
>
> Container task to track commits to update the dependency chain for the EJB3 Plugin 1.0.9 release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 14:22:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 14:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1839) Implement
 POJO-based, @ManagedObject Session Metrics
In-Reply-To: <32587729.1243384676916.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5895754.1244830976584.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated EJBTHREE-1839:
------------------------------------------

    Fix Version/s: 1.1.8
                       (was: 1.1.7)


> Implement POJO-based, @ManagedObject Session Metrics
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1839
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1839
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: metrics-deployer
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.8
>
>         Attachments: metrics.patch
>
>
> Defined by JBAS-6624.
> Consoles need Statistics accessible via ProfileService and jboss-management @ManagedObjects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 14:22:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 14:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1831) Clean up
	dependency chains
In-Reply-To: <13433231.1242136368008.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10267537.1244830976810.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated EJBTHREE-1831:
------------------------------------------

    Fix Version/s: 1.1.8
                       (was: 1.1.7)


> Clean up dependency chains
> --------------------------
>
>                 Key: EJBTHREE-1831
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1831
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: as-int, ejb3
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.8
>
>
> The true order should be:
> jboss-ejb3 > as-int > AS
> jboss-ejb3 > Plugin
> Whereas now as-int goes into Plugin.  Also endpoint-deployer should be included in as-int and Plugin, and not explicitly declared by AS itself.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 14:22:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 14:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1814)
 NoPassivationCache does not obey maxSize
In-Reply-To: <17499438.1240909569920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23256624.1244830976956.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated EJBTHREE-1814:
------------------------------------------

    Fix Version/s: 1.1.8
                       (was: 1.1.7)


> NoPassivationCache does not obey maxSize
> ----------------------------------------
>
>                 Key: EJBTHREE-1814
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1814
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: cache
>            Reporter: Carlo de Wolf
>             Fix For: 1.1.8
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 14:28:57 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Fri, 12 Jun 2009 14:28:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7013) Seam Booking
 IOException with JSF2 Beta1 on AS5
Message-ID: <23174748.1244831337615.JavaMail.jira@cloud.prod.atl2.jboss.com>

Seam Booking IOException with JSF2 Beta1 on AS5
-----------------------------------------------

                 Key: JBAS-7013
                 URL: https://jira.jboss.org/jira/browse/JBAS-7013
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Stan Silvert
            Assignee: Stan Silvert


I drop-in replaced JSF in AS5.1 with JSF 2 Beta 1.  

With the Seam Booking demo, I bundle the old facelets and have:
   <context-param>
      <param-name>javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER</param-name>
      <param-value>true</param-value>
    </context-param>

I get the stack trace below.  Though it doesn't seem to affect the application, I need to figure out why this is happening.

13:38:34,463 ERROR [compiler] Error Loading Library: vfszip:/C:/jboss-5.1.0.GA/s
erver/default/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.tag
lib.xml
java.io.IOException: Error parsing [vfszip:/C:/jboss-5.1.0.GA/server/default/dep
loy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.taglib.xml]:
        at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.ja
va:410)
        at com.sun.facelets.compiler.TagLibraryConfig.loadImplicit(TagLibraryCon
fig.java:431)
        at com.sun.facelets.compiler.Compiler.initialize(Compiler.java:87)
        at com.sun.facelets.compiler.Compiler.compile(Compiler.java:104)
        at com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFace
letFactory.java:218)
        at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFacelet
Factory.java:149)
        at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFacelet
Factory.java:100)
        at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java
:517)
        at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.jav
a:567)
        at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWra
pper.java:108)
        at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.j
ava:216)
        at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePha
se.java:124)
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:103)
        at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:311)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:83)
        at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:69)
        at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:69)
        at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:69)
        at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:69)
        at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)

        at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
        at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:69)
        at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:69)
        at org.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
.java:69)
        at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFi
lter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:235)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:191)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(Securit
yAssociationValve.java:190)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValv
e.java:92)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.proce
ss(SecurityContextEstablishmentValve.java:126)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invok
e(SecurityContextEstablishmentValve.java:70)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:102)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedC
onnectionValve.java:158)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:330)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:829)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
ss(Http11Protocol.java:598)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44
7)
        at java.lang.Thread.run(Thread.java:619)
Caused by: org.xml.sax.SAXException: Error Handling [vfszip:/C:/jboss-5.1.0.GA/s
erver/default/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.tag
lib.xml at 42,29]
        at com.sun.facelets.compiler.TagLibraryConfig$LibraryHandler.error(TagLi
braryConfig.java:376)
        at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
        at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
        at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
        at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
        at org.apache.xerces.impl.dtd.XMLDTDValidator.rootElementSpecified(Unkno
wn Source)
        at org.apache.xerces.impl.dtd.XMLDTDValidator.handleStartElement(Unknown
 Source)
        at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Sourc
e)
        at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElemen
t(Unknown Source)
        at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanR
ootElementHook(Unknown Source)
        at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
Dispatcher.dispatch(Unknown Source)
        at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un
known Source)
        at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
        at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
        at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
        at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
        at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Sour
ce)
        at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
        at javax.xml.parsers.SAXParser.parse(SAXParser.java:198)
        at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.ja
va:407)
        ... 54 more
Caused by: org.xml.sax.SAXParseException: Document root element "facelet-taglib"
, must match DOCTYPE root "null".
        at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Un
known Source)
        ... 73 more


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 15:08:56 2009
From: jira-events at lists.jboss.org (Duane Olawsky (JIRA))
Date: Fri, 12 Jun 2009 15:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-990) Grammatical Error in
 log message: I'm being am suspected.
Message-ID: <15502315.1244833736783.JavaMail.jira@cloud.prod.atl2.jboss.com>

Grammatical Error in log message: I'm being am suspected.
---------------------------------------------------------

                 Key: JGRP-990
                 URL: https://jira.jboss.org/jira/browse/JGRP-990
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.4.1
         Environment: N/A
            Reporter: Duane Olawsky
            Assignee: Bela Ban
            Priority: Trivial


There is a grammatical error in the following log message:

"WARN - I am the coord and I'm being am suspected -- will probably leave shortly"

I suggest removing the second "am".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 15:49:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 12 Jun 2009 15:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7014) JChannelFactory
 addSingletonName handling broken
Message-ID: <26543394.1244836196419.JavaMail.jira@cloud.prod.atl2.jboss.com>

JChannelFactory addSingletonName handling broken
------------------------------------------------

                 Key: JBAS-7014
                 URL: https://jira.jboss.org/jira/browse/JBAS-7014
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.1.0.CR1
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-5.2.0.Beta1


The expected path for the AS JChannelFactory's addSingletonName logic is broken -- it thinks it is mutating the passed in config but it isn't.

Luckily this is minor because there's separate logic that executes when JGroups throws an UnsupportedOperationException -- said logic works correctly and JGroups always throws the exception. But if a later release of JGroups fixed the UOE, this bug would be exposed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 15:59:56 2009
From: jira-events at lists.jboss.org (Gavin King (JIRA))
Date: Fri, 12 Jun 2009 15:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1245515.1244836796622.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gavin King reopened EJBTHREE-995:
---------------------------------



What?! This is a major bug that is easy to reproduce. No I'm not going to write the tests. This affects Seam and anyone who uses SessionSynchronization.

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 16:09:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 12 Jun 2009 16:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7015) AS JChannelFactory
 should always add singleton_name
Message-ID: <10577550.1244837396926.JavaMail.jira@cloud.prod.atl2.jboss.com>

AS JChannelFactory should always add singleton_name
---------------------------------------------------

                 Key: JBAS-7015
                 URL: https://jira.jboss.org/jira/browse/JBAS-7015
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-6.0.0.Alpha1


Currently it only adds a singleton_name if channel is requested via createMultiplexerChannel() methods, not for createChannel(String stack). But the latter will possibly become the default, and if two services request channels from the same stack and there is no singleton_name, there will be conflicts. The AS should use a shared transport whenever possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 17:05:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 12 Jun 2009 17:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7015) AS JChannelFactory
 should always add singleton_name
In-Reply-To: <10577550.1244837396926.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6571304.1244840756501.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471980#action_12471980 ] 

Brian Stansberry commented on JBAS-7015:
----------------------------------------

Qualifying the title: it should always add singleton_name if the API methods that provide a stack_name are used. It won't create a singleton_name if createChannel(Object properties) is invoked as in that case there is no stack_name to serve as an indicator that the given config has been used before.

> AS JChannelFactory should always add singleton_name
> ---------------------------------------------------
>
>                 Key: JBAS-7015
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7015
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Currently it only adds a singleton_name if channel is requested via createMultiplexerChannel() methods, not for createChannel(String stack). But the latter will possibly become the default, and if two services request channels from the same stack and there is no singleton_name, there will be conflicts. The AS should use a shared transport whenever possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 17:07:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 12 Jun 2009 17:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7016) Management interface
 for JChannelFactory
Message-ID: <9111063.1244840876545.JavaMail.jira@cloud.prod.atl2.jboss.com>

Management interface for JChannelFactory
----------------------------------------

                 Key: JBAS-7016
                 URL: https://jira.jboss.org/jira/browse/JBAS-7016
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 17:24:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 17:24:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2576296.1244841897115.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated EJBTHREE-995:
-----------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237390


> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 17:24:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 12 Jun 2009 17:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11531522.1244841896711.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471981#action_12471981 ] 

Andrew Lee Rubinger commented on EJBTHREE-995:
----------------------------------------------

Collaboration is more effective than persistent complaints.

For starters, please check the test I've added to ensure that it covers the issue you describe.  I've opened a forum Thread for discussion.

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 17:56:56 2009
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Fri, 12 Jun 2009 17:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16770319.1244843816556.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBWEB-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471983#action_12471983 ] 

Remy Maucherat commented on JBWEB-144:
--------------------------------------

So I suppose your plan is to merge this patch chain in the CP branch ?

> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 12 20:19:57 2009
From: jira-events at lists.jboss.org (Daniel munford (JIRA))
Date: Fri, 12 Jun 2009 20:19:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6590) AS5 is not
 reliably picking up changes in exploded EAR
In-Reply-To: <5022560.1236474262651.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28970234.1244852397592.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471988#action_12471988 ] 

Daniel munford commented on JBAS-6590:
--------------------------------------

I have confirmed that this is still happening in JBoss AS 5.1.0 GA release.  Is there an ETA on when the bug will be fixed?

> AS5 is not reliably picking up changes in exploded EAR
> ------------------------------------------------------
>
>                 Key: JBAS-6590
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6590
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: JBoss AS 5.0.1.GA
> JDK 1.5
> Mac OS X 10.5.6
>            Reporter: Kenneth Christensen
>            Assignee: Ales Justin
>            Priority: Critical
>         Attachments: ear.jpg, jboss5-test.ear.zip, tmp-ear.jpg
>
>
> I have an explode ear file (directory) - see attached file: ear.jpg
> When I deploy the exploded ear file to JBoss AS 4.2.3 and later want to update a xhtml file in the exploded ear by my ANT script everything works fine (i.e. I can refresh my browser and see the changes without redeployment of the ear or war):
>     <!-- Target: deploy.xhtml.to.jboss -->
>     <target name="deploy.xhtml.to.jboss" description="Deploy xhtml files to JBoss" if="deployed">
>         <copy todir="${jboss.deploy.dir}/${jboss.context.path}/${war.file.name}/xhtml">
>             <fileset dir="${view.dir}/xhtml" includes="**/*"/>
>         </copy>
>     </target>
> Because the exploded ear file is not copied to JBoss tmp dir.
> But JBoss AS 5 always makes a copy of my exploded ear file and copies it to the tmp dir where it's the current 'working copy/version' used by JBoss AS - see attached file: tmp-ear.jpg
> My ANT task will not work anymore because the 'working copy/version' used by JBoss AS now is in the tmp dir and not in the deploy dir.
> I really don't want to 'touch' web.xml (or other meta files) to trigger a full redeployment when I need to make changes to my web files (xhtml, css, javascript, images etc.).
> Could we please have the 'old' behaviour from JBoss AS 4.2.X implemented into JBoss AS 5 - or is there a workaround to above problem?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 13 02:14:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 13 Jun 2009 02:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-990) Grammatical Error in
 log message: I'm being am suspected.
In-Reply-To: <15502315.1244833736783.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30995966.1244873697135.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-990:
--------------------------

    Fix Version/s: 2.4.7


> Grammatical Error in log message: I'm being am suspected.
> ---------------------------------------------------------
>
>                 Key: JGRP-990
>                 URL: https://jira.jboss.org/jira/browse/JGRP-990
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.1
>         Environment: N/A
>            Reporter: Duane Olawsky
>            Assignee: Bela Ban
>            Priority: Trivial
>             Fix For: 2.4.7
>
>
> There is a grammatical error in the following log message:
> "WARN - I am the coord and I'm being am suspected -- will probably leave shortly"
> I suggest removing the second "am".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 13 07:21:57 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Sat, 13 Jun 2009 07:21:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6590) AS5 is not
 reliably picking up changes in exploded EAR
In-Reply-To: <5022560.1236474262651.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19720572.1244892117745.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471994#action_12471994 ] 

Ales Justin commented on JBAS-6590:
-----------------------------------

>> I have confirmed that this is still happening in JBoss AS 5.1.0 GA release. Is there an ETA on when the bug will be fixed? 

Yes, this was already filed under JBDEPLOY-192.
It will be resolved with a new Deployers release.

> AS5 is not reliably picking up changes in exploded EAR
> ------------------------------------------------------
>
>                 Key: JBAS-6590
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6590
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: JBoss AS 5.0.1.GA
> JDK 1.5
> Mac OS X 10.5.6
>            Reporter: Kenneth Christensen
>            Assignee: Ales Justin
>            Priority: Critical
>         Attachments: ear.jpg, jboss5-test.ear.zip, tmp-ear.jpg
>
>
> I have an explode ear file (directory) - see attached file: ear.jpg
> When I deploy the exploded ear file to JBoss AS 4.2.3 and later want to update a xhtml file in the exploded ear by my ANT script everything works fine (i.e. I can refresh my browser and see the changes without redeployment of the ear or war):
>     <!-- Target: deploy.xhtml.to.jboss -->
>     <target name="deploy.xhtml.to.jboss" description="Deploy xhtml files to JBoss" if="deployed">
>         <copy todir="${jboss.deploy.dir}/${jboss.context.path}/${war.file.name}/xhtml">
>             <fileset dir="${view.dir}/xhtml" includes="**/*"/>
>         </copy>
>     </target>
> Because the exploded ear file is not copied to JBoss tmp dir.
> But JBoss AS 5 always makes a copy of my exploded ear file and copies it to the tmp dir where it's the current 'working copy/version' used by JBoss AS - see attached file: tmp-ear.jpg
> My ANT task will not work anymore because the 'working copy/version' used by JBoss AS now is in the tmp dir and not in the deploy dir.
> I really don't want to 'touch' web.xml (or other meta files) to trigger a full redeployment when I need to make changes to my web files (xhtml, css, javascript, images etc.).
> Could we please have the 'old' behaviour from JBoss AS 4.2.X implemented into JBoss AS 5 - or is there a workaround to above problem?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 14 11:36:04 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Sun, 14 Jun 2009 11:36:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1456) Messages
 stuck in being-delivered state in cluster
In-Reply-To: <18231416.1227029676624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14663923.1244993764331.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472015#action_12472015 ] 

Howard Gao commented on JBMESSAGING-1456:
-----------------------------------------

Thanks Victor. Please note that:

1. If you have long live sessions, it is possible the messages got 'stuck' until the session is closed.
2. if session is not closed while failover is happening, the following parameter affects how long the messages will be canceled back to queue for redelivery:

<attribute name="clientLeasePeriod" isParam="true">30000</attribute> 

For the above value, the 'stuck' message will not be canceled back until at least 30 sec after the client has finished failover.



> Messages stuck in being-delivered state in cluster
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1456
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>         Attachments: DeliveringCount.png, kill3_thread_dump.txt, logs-and-config.zip, MessageStucked.png, RemoveAllMessagesException.png, test-1456-jars.zip, thread_dump.txt
>
>
> Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
> JBoss setup:
>   -2 nodes of JBoss EAP 4.3 CP02
>   -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
>   -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
> Client setup:
>   -both nodes have a client which is a separate process (i.e. not inside JBoss)
>   -clients are Spring based
>   -one client produces and consumes, the other client just consumes
>   -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
>   -both clients publish to and consume from "queue/testDistributedQueue"
>   -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
> Symptoms of the issue:
>   -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
>   -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
>   -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
>   -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
>   -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
>   -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
>   -a "killall -3 java" doesn't produce anything from the clients so I know their dead
>   -nothing is in any DLQ or expiry queue
>   -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
>   -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
> Other notes:
>   -nothing else is happening on either node but running the client and running JBoss
>   -this only appears to happen when a clustered connection factory is used.  I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 14 17:09:57 2009
From: jira-events at lists.jboss.org (Przemyslaw Rozycki (JIRA))
Date: Sun, 14 Jun 2009 17:09:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1946) Deserializing a
 KnowledgeBase object throws a java.io.EOFException
In-Reply-To: <13586666.1233155564971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16770076.1245013797192.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472021#action_12472021 ] 

Przemyslaw Rozycki commented on JBRULES-1946:
---------------------------------------------

Unfortunately, I use 5.0.1 and still have this problem. I will attach my example which is a bit simpler. Please, reopen the case (I can't).

> Deserializing a KnowledgeBase object throws a java.io.EOFException
> ------------------------------------------------------------------
>
>                 Key: JBRULES-1946
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1946
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions:  5.0.0.M4, 5.0.0.M5
>         Environment: Ubuntu 8.10
>            Reporter: Simon Kelly
>            Assignee: Edson Tirelli
>             Fix For: 5.0.1.FINAL
>
>         Attachments: drools.test.zip, DroolsTest.java, Sample.drl
>
>
> A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file.
> java.io.EOFException
> 	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
> 	at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
> 	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
> 	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49)
> 	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227)
> 	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173)
> 	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at com.sample.DroolsTest.read(DroolsTest.java:75)
> 	at com.sample.DroolsTest.testIO(DroolsTest.java:50)
> 	at com.sample.DroolsTest.main(DroolsTest.java:40)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 14 17:23:56 2009
From: jira-events at lists.jboss.org (Przemyslaw Rozycki (JIRA))
Date: Sun, 14 Jun 2009 17:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1946) Deserializing a
 KnowledgeBase object throws a java.io.EOFException
In-Reply-To: <13586666.1233155564971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21415106.1245014636767.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Przemyslaw Rozycki updated JBRULES-1946:
----------------------------------------

    Attachment: Sandbox2.java


A Java test code.

> Deserializing a KnowledgeBase object throws a java.io.EOFException
> ------------------------------------------------------------------
>
>                 Key: JBRULES-1946
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1946
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions:  5.0.0.M4, 5.0.0.M5
>         Environment: Ubuntu 8.10
>            Reporter: Simon Kelly
>            Assignee: Edson Tirelli
>             Fix For: 5.0.1.FINAL
>
>         Attachments: drools.test.zip, DroolsTest.java, Sample.drl, Sandbox2.java
>
>
> A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file.
> java.io.EOFException
> 	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
> 	at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
> 	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
> 	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49)
> 	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227)
> 	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173)
> 	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at com.sample.DroolsTest.read(DroolsTest.java:75)
> 	at com.sample.DroolsTest.testIO(DroolsTest.java:50)
> 	at com.sample.DroolsTest.main(DroolsTest.java:40)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 14 17:25:56 2009
From: jira-events at lists.jboss.org (Przemyslaw Rozycki (JIRA))
Date: Sun, 14 Jun 2009 17:25:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1946) Deserializing a
 KnowledgeBase object throws a java.io.EOFException
In-Reply-To: <13586666.1233155564971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28531165.1245014756541.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Przemyslaw Rozycki updated JBRULES-1946:
----------------------------------------

    Attachment: Sample1.drl


Test rules. In fact, it doesn't really matter what rules I use.

> Deserializing a KnowledgeBase object throws a java.io.EOFException
> ------------------------------------------------------------------
>
>                 Key: JBRULES-1946
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1946
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions:  5.0.0.M4, 5.0.0.M5
>         Environment: Ubuntu 8.10
>            Reporter: Simon Kelly
>            Assignee: Edson Tirelli
>             Fix For: 5.0.1.FINAL
>
>         Attachments: drools.test.zip, DroolsTest.java, Sample.drl, Sample1.drl, Sandbox2.java
>
>
> A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file.
> java.io.EOFException
> 	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
> 	at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
> 	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
> 	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49)
> 	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227)
> 	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173)
> 	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at com.sample.DroolsTest.read(DroolsTest.java:75)
> 	at com.sample.DroolsTest.testIO(DroolsTest.java:50)
> 	at com.sample.DroolsTest.main(DroolsTest.java:40)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 02:45:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 15 Jun 2009 02:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1644) Work out a
 suitable way to provide JBM examples/doc for AS 5
In-Reply-To: <25933843.1244563136418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26541853.1245048356528.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472037#action_12472037 ] 

Howard Gao commented on JBMESSAGING-1644:
-----------------------------------------

Currently the standard download of AS 5 doesn't include the docs/examples of JBoss Messaging. That makes it hard for new users to learn how to configure and use JBoss Messaging that comes with AS 5 distribution. A lot of questions that the users put to the forum wouldn't have been necessary had there been an easy way to let users get the examples and documents.

However the current structure of a AS 5 distribution structure is not so ready to adapt those doc/example stuff, so I'm trying to find a way to fit in those bits.

My idea is to provide an extra distribution for AS 5. It is a single zip file downloadable along side with the JBoss AS 5 kit on the download page. The name is to be like:

jboss-5.1.0.GA-extra.zip

Once unzipped, it should have the following structure:

jboss-5.1.0.GA/
                       |
                       |----- extra/
                                      |----readme.txt (table of contents)
                                      |
                                      |----jboss-messaging
                                      |                             |
                                      |                             |-----doc
                                      |                             |
                                      |                             |------examples
                                      |
                                      |----other stuffs

This is let the whole stuff be easily copied to an existing AS 5 installation, resulting in an additional /extra sub dir under $JBOSS_HOME.

I believe this method not only address the issue of JBoss Messaging examples/doc, but also can provide a place for some other pieces that are not runtime essential to AS 5. For example, some of the stuff under the docs/ dir is not necessary for a server to startup and many of the files are not related to documentation. Such stuff like that can also goes to the extra package and that will make the AS 5 distribution more concise and slim.

That can benefits both advanced users and novices. For advanced users they don't need to download stuff they don't need. For novices they can easily find more resources regarding to all the supporting components (messaging, transactions, security etc) and get on quickly. That also save many core developers from answering obvious questions. Also this way the users can get the right versions with each release of AS 5 without having to finding out versions of those components within.

To do this, it needs to:

1. Put the extra stuff to somewhere under AS5's maven repository.
2. Add a build target 'extra' to  generate the extra package.
3. Upload the extra zip to the dowload page for AS5.


> Work out a suitable way to provide JBM examples/doc for AS 5
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1644
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1644
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.5.GA
>
>
> Current AS 5 distribution kit doesn't have JBM doc/examples of the corresponding version included, that makes it very inconvenient to use JBM with AS5. Users often get confused with which version of JBM is the correct version, and where to get the resouces (docs, examples).
> We have to provide a solution to that. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 03:40:57 2009
From: jira-events at lists.jboss.org (Ivelin Velkov (JIRA))
Date: Mon, 15 Jun 2009 03:40:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <382983.1245051657118.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472038#action_12472038 ] 

Ivelin Velkov commented on JBAS-6888:
-------------------------------------

Hi, we are going in production very soon. QA testing for about a month didn't find an issue with the above workaround.

> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Flavia Rainone
>         Attachments: server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 04:24:03 2009
From: jira-events at lists.jboss.org (Vicky Kak (JIRA))
Date: Mon, 15 Jun 2009 04:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1429) Reauthentication
	Support
Message-ID: <10646240.1245054243425.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vicky Kak updated JBAS-1429:
----------------------------

    Attachment: JBAS-1429


> Reauthentication Support
> ------------------------
>
>                 Key: JBAS-1429
>                 URL: https://jira.jboss.org/jira/browse/JBAS-1429
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Andrew Oliver
>            Assignee: Vicky Kak
>         Attachments: JBAS-1429
>
>
> Add support for the reauthentication support (in particular MySQLChangeUser)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 04:26:56 2009
From: jira-events at lists.jboss.org (Vicky Kak (JIRA))
Date: Mon, 15 Jun 2009 04:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1429) Reauthentication
	Support
Message-ID: <14458392.1245054416791.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vicky Kak updated JBAS-1429:
----------------------------

    Attachment: ReauthenticationMechansim.java


> Reauthentication Support
> ------------------------
>
>                 Key: JBAS-1429
>                 URL: https://jira.jboss.org/jira/browse/JBAS-1429
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Andrew Oliver
>            Assignee: Vicky Kak
>         Attachments: JBAS-1429, ReauthenticationMechansim.java
>
>
> Add support for the reauthentication support (in particular MySQLChangeUser)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 04:28:56 2009
From: jira-events at lists.jboss.org (Vicky Kak (JIRA))
Date: Mon, 15 Jun 2009 04:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1429) Reauthentication
	Support
Message-ID: <29449832.1245054536954.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vicky Kak updated JBAS-1429:
----------------------------

    Attachment: MySqlReauthenticationMechansimImpl.java


> Reauthentication Support
> ------------------------
>
>                 Key: JBAS-1429
>                 URL: https://jira.jboss.org/jira/browse/JBAS-1429
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Andrew Oliver
>            Assignee: Vicky Kak
>         Attachments: JBAS-1429, MySqlReauthenticationMechansimImpl.java, ReauthenticationMechansim.java
>
>
> Add support for the reauthentication support (in particular MySQLChangeUser)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 04:31:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 15 Jun 2009 04:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7017) Upgrade EJB3 to 1.1.7
Message-ID: <8087911.1245054716478.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade EJB3 to 1.1.7
---------------------

                 Key: JBAS-7017
                 URL: https://jira.jboss.org/jira/browse/JBAS-7017
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
          Components: EJB3
            Reporter: jaikiran pai
            Assignee: jaikiran pai
             Fix For: JBossAS-5.2.0.Beta1


EJB3 1.1.7 version has been released. Update the AS to use this new version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 04:33:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 15 Jun 2009 04:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7018) Upgrade EJB3 to 1.1.7
Message-ID: <25050850.1245054836512.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade EJB3 to 1.1.7
---------------------

                 Key: JBAS-7018
                 URL: https://jira.jboss.org/jira/browse/JBAS-7018
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
          Components: EJB3
            Reporter: jaikiran pai
            Assignee: jaikiran pai
             Fix For: JBossAS-6.0.0.Alpha1


Update the AS to use the newly released EJB3 1.1.7 version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 04:35:56 2009
From: jira-events at lists.jboss.org (Vicky Kak (JIRA))
Date: Mon, 15 Jun 2009 04:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1429) Reauthentication
	Support
Message-ID: <29368601.1245054956870.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472044#action_12472044 ] 

Vicky Kak commented on JBAS-1429:
---------------------------------

Few things to be considered here are 

1) The MySqlReauthenticationMechanism will not work unless changeUser(..) method is added to com.mysql.jdbc.jdbc2.optional.ConnectionWrapper class,
************************************************************************* 
public void changeUser(String userName, String newPassword) throws SQLException {
		checkClosed();

		try {
			this.mc.changeUser(userName,newPassword);
		} catch (SQLException sqlException) {
			checkAndFireConnectionError(sqlException);
		}
	}
************************************************************************* 
2) The unit tests for this change needs to be incorporated.


> Reauthentication Support
> ------------------------
>
>                 Key: JBAS-1429
>                 URL: https://jira.jboss.org/jira/browse/JBAS-1429
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Andrew Oliver
>            Assignee: Vicky Kak
>         Attachments: JBAS-1429, MySqlReauthenticationMechansimImpl.java, ReauthenticationMechansim.java
>
>
> Add support for the reauthentication support (in particular MySQLChangeUser)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 05:04:57 2009
From: jira-events at lists.jboss.org (Przemyslaw Rozycki (JIRA))
Date: Mon, 15 Jun 2009 05:04:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1946) Deserializing a
 KnowledgeBase object throws a java.io.EOFException
In-Reply-To: <13586666.1233155564971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22447036.1245056697696.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472048#action_12472048 ] 

Przemyslaw Rozycki commented on JBRULES-1946:
---------------------------------------------

I also tried on the code from trunk (revision 26960) and the problem occurs. All the more I ask for reopening the bug.


> Deserializing a KnowledgeBase object throws a java.io.EOFException
> ------------------------------------------------------------------
>
>                 Key: JBRULES-1946
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1946
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions:  5.0.0.M4, 5.0.0.M5
>         Environment: Ubuntu 8.10
>            Reporter: Simon Kelly
>            Assignee: Edson Tirelli
>             Fix For: 5.0.1.FINAL
>
>         Attachments: drools.test.zip, DroolsTest.java, Sample.drl, Sample1.drl, Sandbox2.java
>
>
> A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file.
> java.io.EOFException
> 	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
> 	at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
> 	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
> 	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49)
> 	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227)
> 	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173)
> 	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at com.sample.DroolsTest.read(DroolsTest.java:75)
> 	at com.sample.DroolsTest.testIO(DroolsTest.java:50)
> 	at com.sample.DroolsTest.main(DroolsTest.java:40)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 06:01:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 15 Jun 2009 06:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1656) Time out
 sessions nearer to connection ttl
Message-ID: <27237646.1245060116436.JavaMail.jira@cloud.prod.atl2.jboss.com>

Time out sessions nearer to connection ttl
------------------------------------------

                 Key: JBMESSAGING-1656
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1656
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
            Assignee: Tim Fox
             Fix For: 2.0.0.beta2


Currently, sessions on the server can be timed out up to 2 * connection TTL ms after a ping has arrived on the server, due to the way pinging and failure checking is done.

We can refactor this somewhat to make sessions timeout much nearer to connection ttl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 06:10:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 15 Jun 2009 06:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7019) Fork the existing
 tomcat integration code from AS into Spider
Message-ID: <22128270.1245060656840.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fork the existing tomcat integration code from AS into Spider
-------------------------------------------------------------

                 Key: JBAS-7019
                 URL: https://jira.jboss.org/jira/browse/JBAS-7019
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 06:10:57 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 15 Jun 2009 06:10:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7020) Remove AS
 dependencies and create SPIs
Message-ID: <25343710.1245060657193.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remove AS dependencies and create SPIs
--------------------------------------

                 Key: JBAS-7020
                 URL: https://jira.jboss.org/jira/browse/JBAS-7020
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 06:12:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 15 Jun 2009 06:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7021) Create a JBoss Spider
 distribution
Message-ID: <9103344.1245060776647.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create a JBoss Spider distribution
----------------------------------

                 Key: JBAS-7021
                 URL: https://jira.jboss.org/jira/browse/JBAS-7021
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Carlo de Wolf




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 06:12:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 15 Jun 2009 06:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7021) Create a JBoss
 Spider distribution
In-Reply-To: <9103344.1245060776647.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12157312.1245060776899.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf reassigned JBAS-7021:
-----------------------------------

    Assignee: Carlo de Wolf


> Create a JBoss Spider distribution
> ----------------------------------
>
>                 Key: JBAS-7021
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7021
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 06:42:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 15 Jun 2009 06:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1656) Time out
 sessions nearer to connection ttl
In-Reply-To: <27237646.1245060116436.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21503170.1245062576815.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-1656.
--------------------------------

    Resolution: Done


> Time out sessions nearer to connection ttl
> ------------------------------------------
>
>                 Key: JBMESSAGING-1656
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1656
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0.beta2
>
>
> Currently, sessions on the server can be timed out up to 2 * connection TTL ms after a ping has arrived on the server, due to the way pinging and failure checking is done.
> We can refactor this somewhat to make sessions timeout much nearer to connection ttl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 07:57:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 15 Jun 2009 07:57:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-1946) Deserializing a
 KnowledgeBase object throws a java.io.EOFException
In-Reply-To: <13586666.1233155564971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20190254.1245067077927.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reopened JBRULES-1946:
------------------------------------



Reopening by user request. Need to check the new test cases.

> Deserializing a KnowledgeBase object throws a java.io.EOFException
> ------------------------------------------------------------------
>
>                 Key: JBRULES-1946
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1946
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions:  5.0.0.M4, 5.0.0.M5
>         Environment: Ubuntu 8.10
>            Reporter: Simon Kelly
>            Assignee: Edson Tirelli
>             Fix For: 5.0.1.FINAL
>
>         Attachments: drools.test.zip, DroolsTest.java, Sample.drl, Sample1.drl, Sandbox2.java
>
>
> A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file.
> java.io.EOFException
> 	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
> 	at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
> 	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
> 	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49)
> 	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227)
> 	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173)
> 	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at com.sample.DroolsTest.read(DroolsTest.java:75)
> 	at com.sample.DroolsTest.testIO(DroolsTest.java:50)
> 	at com.sample.DroolsTest.main(DroolsTest.java:40)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 08:54:07 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Mon, 15 Jun 2009 08:54:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-129)
 java.util.ConcurrentModificationException in HibernateIdentityStoreImpl
 class
Message-ID: <8734936.1245070447420.JavaMail.jira@cloud.prod.atl2.jboss.com>

java.util.ConcurrentModificationException in HibernateIdentityStoreImpl class
-----------------------------------------------------------------------------

                 Key: JBID-129
                 URL: https://jira.jboss.org/jira/browse/JBID-129
             Project: JBoss Identity
          Issue Type: Bug
          Components: IDM
    Affects Versions: idm-1.0.0.Alpha5
            Reporter: Jeff Yu
            Assignee: Jeff Yu
             Fix For: IDFED-1.0.0.beta1



The test case for this error is:

      Group dept = identitySession.getPersistenceManager().createGroup("sales-dept", GROUP);
      User u1 = identitySession.getPersistenceManager().createUser("jeff1");
      User u2 = identitySession.getPersistenceManager().createUser("jeff2");
      RoleType developer = identitySession.getRoleManager().createRoleType("developer");
      identitySession.getRoleManager().createRole(developer, u1, dept);
      identitySession.getRoleManager().createRole(developer, u2, dept);
      
      identitySession.getPersistenceManager().removeGroup(dept, true);
----------------------------------------------------------------------------------------------


Exception stack:
------------------------------------
Caused by: java.util.ConcurrentModificationException
    at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
    at java.util.HashMap$KeyIterator.next(HashMap.java:877)
    at org.hibernate.collection.AbstractPersistentCollection$IteratorProxy.next(AbstractPersistentCollection.java:577)
    at org.jboss.identity.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:500)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 08:55:57 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Mon, 15 Jun 2009 08:55:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-129)
 java.util.ConcurrentModificationException in HibernateIdentityStoreImpl
 class
In-Reply-To: <8734936.1245070447420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6256363.1245070557506.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Yu updated JBID-129:
-------------------------

    Fix Version/s: idm-1.0.0.Beta1
                       (was: IDFED-1.0.0.beta1)


> java.util.ConcurrentModificationException in HibernateIdentityStoreImpl class
> -----------------------------------------------------------------------------
>
>                 Key: JBID-129
>                 URL: https://jira.jboss.org/jira/browse/JBID-129
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: IDM
>    Affects Versions: idm-1.0.0.Alpha5
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> The test case for this error is:
>       Group dept = identitySession.getPersistenceManager().createGroup("sales-dept", GROUP);
>       User u1 = identitySession.getPersistenceManager().createUser("jeff1");
>       User u2 = identitySession.getPersistenceManager().createUser("jeff2");
>       RoleType developer = identitySession.getRoleManager().createRoleType("developer");
>       identitySession.getRoleManager().createRole(developer, u1, dept);
>       identitySession.getRoleManager().createRole(developer, u2, dept);
>       
>       identitySession.getPersistenceManager().removeGroup(dept, true);
> ----------------------------------------------------------------------------------------------
> Exception stack:
> ------------------------------------
> Caused by: java.util.ConcurrentModificationException
>     at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
>     at java.util.HashMap$KeyIterator.next(HashMap.java:877)
>     at org.hibernate.collection.AbstractPersistentCollection$IteratorProxy.next(AbstractPersistentCollection.java:577)
>     at org.jboss.identity.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:500)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 08:55:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Mon, 15 Jun 2009 08:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Work started: (JBID-129)
 java.util.ConcurrentModificationException in HibernateIdentityStoreImpl
 class
In-Reply-To: <8734936.1245070447420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16759279.1245070556683.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on JBID-129 started by Jeff Yu.

> java.util.ConcurrentModificationException in HibernateIdentityStoreImpl class
> -----------------------------------------------------------------------------
>
>                 Key: JBID-129
>                 URL: https://jira.jboss.org/jira/browse/JBID-129
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: IDM
>    Affects Versions: idm-1.0.0.Alpha5
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> The test case for this error is:
>       Group dept = identitySession.getPersistenceManager().createGroup("sales-dept", GROUP);
>       User u1 = identitySession.getPersistenceManager().createUser("jeff1");
>       User u2 = identitySession.getPersistenceManager().createUser("jeff2");
>       RoleType developer = identitySession.getRoleManager().createRoleType("developer");
>       identitySession.getRoleManager().createRole(developer, u1, dept);
>       identitySession.getRoleManager().createRole(developer, u2, dept);
>       
>       identitySession.getPersistenceManager().removeGroup(dept, true);
> ----------------------------------------------------------------------------------------------
> Exception stack:
> ------------------------------------
> Caused by: java.util.ConcurrentModificationException
>     at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
>     at java.util.HashMap$KeyIterator.next(HashMap.java:877)
>     at org.hibernate.collection.AbstractPersistentCollection$IteratorProxy.next(AbstractPersistentCollection.java:577)
>     at org.jboss.identity.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:500)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 09:01:57 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 15 Jun 2009 09:01:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBID-129)
 java.util.ConcurrentModificationException in HibernateIdentityStoreImpl
 class
In-Reply-To: <8734936.1245070447420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4893155.1245070917102.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBID-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472076#action_12472076 ] 

Anil Saldhana commented on JBID-129:
------------------------------------

ConcurrentHashMap?

> java.util.ConcurrentModificationException in HibernateIdentityStoreImpl class
> -----------------------------------------------------------------------------
>
>                 Key: JBID-129
>                 URL: https://jira.jboss.org/jira/browse/JBID-129
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: IDM
>    Affects Versions: idm-1.0.0.Alpha5
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> The test case for this error is:
>       Group dept = identitySession.getPersistenceManager().createGroup("sales-dept", GROUP);
>       User u1 = identitySession.getPersistenceManager().createUser("jeff1");
>       User u2 = identitySession.getPersistenceManager().createUser("jeff2");
>       RoleType developer = identitySession.getRoleManager().createRoleType("developer");
>       identitySession.getRoleManager().createRole(developer, u1, dept);
>       identitySession.getRoleManager().createRole(developer, u2, dept);
>       
>       identitySession.getPersistenceManager().removeGroup(dept, true);
> ----------------------------------------------------------------------------------------------
> Exception stack:
> ------------------------------------
> Caused by: java.util.ConcurrentModificationException
>     at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
>     at java.util.HashMap$KeyIterator.next(HashMap.java:877)
>     at org.hibernate.collection.AbstractPersistentCollection$IteratorProxy.next(AbstractPersistentCollection.java:577)
>     at org.jboss.identity.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:500)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 09:29:02 2009
From: jira-events at lists.jboss.org (Guy Coleman (JIRA))
Date: Mon, 15 Jun 2009 09:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-200) Validation errors
 in jboss_5_1.xsd
In-Reply-To: <31399568.1242244606768.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12363865.1245072542285.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472077#action_12472077 ] 

Guy Coleman commented on JBMETA-200:
------------------------------------

Please update the copies on the web too (http://www.jboss.org/j2ee/schema etc)

> Validation errors in jboss_5_1.xsd
> ----------------------------------
>
>                 Key: JBMETA-200
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-200
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.0.CR17
>         Environment: Eclipse 3.4, WebToolsPlatform 3.0
>            Reporter: Wolfgang Knauf
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>             Fix For: 1.0.1.GA
>
>
> I tried to create a jboss.xml from jboss_5_1.xsd, using Eclipe/WebTools for validation. To achieve this, I picked newest "jboss_5_1.xsd" and "jboss_common_5_1.xsd"  from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/jboss-common_5_1.xsd) and added them to an eclipse web project. The files at http://www.jboss.org/j2ee/schema/ are much older and with more problems...
> This results in several problems:
> =================
> Import of "javaee_5.xsd"  in jboss_common_5_1.xsd does not point to the web location:
> <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>
> It should be:
> <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>
> =================
> Next one is in "jboss_5_1.xsd"
> cos-nonambig: "http://www.jboss.com/xml/ns/javaee":security-identity and "http://www.jboss.com/xml/ns/javaee":security-identity (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.	jboss_5_1.xsd
> Reason: Element  "security-identity" in "message-driven-beanType" is duplicate.
> Same issue was resolved for jboss_5_0.xsd: https://jira.jboss.org/jira/browse/JBMETA-185
> =================
> jboss_5_1.xsd contains this imports:
>    <xsd:include schemaLocation="jboss-common_5_1.xsd"/>
> It must point to a valid url: http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd
> ================
> And finally: the usage comment talk about "5.0" and "jboss_5_0.xsd", should be 5.1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 09:32:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Mon, 15 Jun 2009 09:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBID-129)
 java.util.ConcurrentModificationException in HibernateIdentityStoreImpl
 class
In-Reply-To: <8734936.1245070447420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7274343.1245072776586.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBID-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472078#action_12472078 ] 

Jeff Yu commented on JBID-129:
------------------------------

Not really,

It is trying to delete the Object when it is in the iterator.next() method.

like:

         for (HibernateIdentityObjectRelationship relationship : hibernateObject.getToRelationships())
         {
            relationship.getFromIdentityObject().getFromRelationships().remove(relationship);
            relationship.getToIdentityObject().getToRelationships().remove(relationship);

            hibernateSession.delete(relationship); // This is causing the error.
         }

> java.util.ConcurrentModificationException in HibernateIdentityStoreImpl class
> -----------------------------------------------------------------------------
>
>                 Key: JBID-129
>                 URL: https://jira.jboss.org/jira/browse/JBID-129
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: IDM
>    Affects Versions: idm-1.0.0.Alpha5
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> The test case for this error is:
>       Group dept = identitySession.getPersistenceManager().createGroup("sales-dept", GROUP);
>       User u1 = identitySession.getPersistenceManager().createUser("jeff1");
>       User u2 = identitySession.getPersistenceManager().createUser("jeff2");
>       RoleType developer = identitySession.getRoleManager().createRoleType("developer");
>       identitySession.getRoleManager().createRole(developer, u1, dept);
>       identitySession.getRoleManager().createRole(developer, u2, dept);
>       
>       identitySession.getPersistenceManager().removeGroup(dept, true);
> ----------------------------------------------------------------------------------------------
> Exception stack:
> ------------------------------------
> Caused by: java.util.ConcurrentModificationException
>     at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
>     at java.util.HashMap$KeyIterator.next(HashMap.java:877)
>     at org.hibernate.collection.AbstractPersistentCollection$IteratorProxy.next(AbstractPersistentCollection.java:577)
>     at org.jboss.identity.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:500)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 09:34:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Mon, 15 Jun 2009 09:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-129)
 java.util.ConcurrentModificationException in HibernateIdentityStoreImpl
 class
In-Reply-To: <8734936.1245070447420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29786283.1245072896506.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Yu resolved JBID-129.
--------------------------

    Resolution: Done


> java.util.ConcurrentModificationException in HibernateIdentityStoreImpl class
> -----------------------------------------------------------------------------
>
>                 Key: JBID-129
>                 URL: https://jira.jboss.org/jira/browse/JBID-129
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: IDM
>    Affects Versions: idm-1.0.0.Alpha5
>            Reporter: Jeff Yu
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> The test case for this error is:
>       Group dept = identitySession.getPersistenceManager().createGroup("sales-dept", GROUP);
>       User u1 = identitySession.getPersistenceManager().createUser("jeff1");
>       User u2 = identitySession.getPersistenceManager().createUser("jeff2");
>       RoleType developer = identitySession.getRoleManager().createRoleType("developer");
>       identitySession.getRoleManager().createRole(developer, u1, dept);
>       identitySession.getRoleManager().createRole(developer, u2, dept);
>       
>       identitySession.getPersistenceManager().removeGroup(dept, true);
> ----------------------------------------------------------------------------------------------
> Exception stack:
> ------------------------------------
> Caused by: java.util.ConcurrentModificationException
>     at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
>     at java.util.HashMap$KeyIterator.next(HashMap.java:877)
>     at org.hibernate.collection.AbstractPersistentCollection$IteratorProxy.next(AbstractPersistentCollection.java:577)
>     at org.jboss.identity.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:500)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 10:50:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 15 Jun 2009 10:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6554) Update jboss-managed
	to 2.1.0.CR2
In-Reply-To: <15314038.1235757645175.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3476605.1245077456696.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBAS-6554:
----------------------------------

    Parent Issue: JBAS-6551  (was: JBAS-6157)


> Update jboss-managed to 2.1.0.CR2
> ---------------------------------
>
>                 Key: JBAS-6554
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6554
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Management services, ProfileService
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> I need to merge the JBAS-6285, platform mbeans managed components changes and update jboss-managed to 2.1.0.CR2. This is to track this until I have time as the 5.x work is the priority.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 10:50:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 15 Jun 2009 10:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-6157) Track component
	updates
In-Reply-To: <20221525.1225727061221.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23736314.1245077457031.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene closed JBAS-6157.
---------------------------------

    Resolution: Duplicate Issue


> Track component updates
> -----------------------
>
>                 Key: JBAS-6157
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6157
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>            Assignee: Dimitris Andreadis
>            Priority: Critical
>             Fix For: JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 10:50:57 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 15 Jun 2009 10:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6551) Track component
 updates - 6.0.0.M1
In-Reply-To: <25977400.1235687384535.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15753316.1245077457233.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBAS-6551:
----------------------------------

    Summary: Track component updates - 6.0.0.M1  (was: Track component updates - 6.0.0.Alpha1)


> Track component updates - 6.0.0.M1
> ----------------------------------
>
>                 Key: JBAS-6551
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6551
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Jason T. Greene
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 10:52:56 2009
From: jira-events at lists.jboss.org (Jonathan Halliday (JIRA))
Date: Mon, 15 Jun 2009 10:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7022) Upgrade JBossTS to
	4.6.1
Message-ID: <13199209.1245077576468.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade JBossTS to 4.6.1
------------------------

                 Key: JBAS-7022
                 URL: https://jira.jboss.org/jira/browse/JBAS-7022
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Jonathan Halliday
            Assignee: Jonathan Halliday




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 11:15:57 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 15 Jun 2009 11:15:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9875646.1245078957244.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472107#action_12472107 ] 

Kabir Khan commented on JBAS-6888:
----------------------------------

Assuming that clazz.getDeclaringClass() is called only in the generated advisor constructor, in GeneratedAdvisorInstrumentor.createAdvisorCtors(), maybe the string should be something like the following

   protected void createAdvisorCtors(CtClass clazz)throws CannotCompileException, NotFoundException
   {
      String initBody =
         "{" +
         "   java.lang.String domainName = org.jboss.aop.Domain.getDomainName(" + clazz.getName() + ".class, $2);" + 
         "   " + DOMAIN + "= new org.jboss.aop.GeneratedAdvisorDomain($1, domainName, " + clazz.getName() + ".class, $2); " +
         "   ((org.jboss.aop.Domain)" + DOMAIN + ").setInheritsBindings(true); " +
         "   super.initialise(" + clazz.getName() + ".class, " + DOMAIN + ");" +
         "}";
}

instead of
   protected void createAdvisorCtors(CtClass clazz)throws CannotCompileException, NotFoundException
   {
      String initBody =
         "{" +
         "   java.lang.String domainName = org.jboss.aop.Domain.getDomainName(" + DECLARING_CLASS + ", $2);" + 
         "   " + DOMAIN + "= new org.jboss.aop.GeneratedAdvisorDomain($1, domainName, " + DECLARING_CLASS + ", $2); " +
         "   ((org.jboss.aop.Domain)" + DOMAIN + ").setInheritsBindings(true); " +
         "   super.initialise(" + DECLARING_CLASS + ", " + DOMAIN + ");" +
         "}";
   }

> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Flavia Rainone
>         Attachments: server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 11:23:57 2009
From: jira-events at lists.jboss.org (Stefan Anzinger (JIRA))
Date: Mon, 15 Jun 2009 11:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-991) ReceiveLocalMessages
 does not work on MuxChannel
Message-ID: <22126121.1245079437238.JavaMail.jira@cloud.prod.atl2.jboss.com>

ReceiveLocalMessages does not work on MuxChannel
------------------------------------------------

                 Key: JGRP-991
                 URL: https://jira.jboss.org/jira/browse/JGRP-991
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.6.10
         Environment: RHEL4 Linux/Windows XP
            Reporter: Stefan Anzinger
            Assignee: Bela Ban


Setting receive local messages to false does not work on Multiplex Channels. Reason for this is, that the local_addr is not set on multiplex channels - therefore the mux channel cannot decide whether this message comes from local or not.

See attached a small testcase. The testcase just gets the local_addr from the "physical channel" and puts it into the MuxChannel local_addr via reflection.
Here is the testcase:

import java.io.ByteArrayInputStream;
import java.lang.reflect.Field;
import org.w3c.dom.*;
import javax.xml.parsers.*;
import junit.framework.TestCase;
import org.jgroups.*;
import org.jgroups.mux.Multiplexer;

public class TestJGroups extends TestCase {
    /**
     * Tests the receiveLocalMessages feature on multiplex
     * channels.
     * 
     * <h2>Course of action</h2>
     * <ol>
     *   <li>Creates tow physical channels</li>
     *   <li>For each physical channel a mux channel is created</li>
     *   <li>Receive Local messages is turned off on the mux channels</li>
     *   <li>Local address has to be set manually after connecting the physical channels (This may be done automatically)</li>
     *   <li>Message is sent from the first mux to the second mux channel</li>
     * </ol>
     * 
     * @throws Exception
     */
    public void testMultiplex() throws Exception {
        JChannelFactory factory = new JChannelFactory(getConfig());
        JChannel c1 = newChannel("c1", (JChannel)factory.createChannel());
        JChannel c2 = newChannel("c2", (JChannel)factory.createChannel());

        JChannel mc1 = newMuxChannel(c1, "mc1");
        JChannel mc2 = newMuxChannel(c2, "mc2");

        mc1.setOpt(Channel.LOCAL, Boolean.FALSE);
        mc2.setOpt(Channel.LOCAL, Boolean.FALSE);
        mc1.connect("X");
        mc2.connect("Y");

        // By commenting this, the messages are also received locally
        setLocalAddress(c1, mc1);   
        setLocalAddress(c2, mc2);
        
        Thread.sleep(2000);
        
        mc1.send(new Message(null, null, "HELLO WORLD"));
        
        Thread.sleep(500);
        
        c2.disconnect();
        c1.disconnect();
    }
    
    private JChannel newMuxChannel(JChannel channel, String name) throws Exception {
        Multiplexer mux = new Multiplexer(channel);
        JChannel mc = (JChannel)mux.createMuxChannel("hello1", "ASDF2");
        
        mc.setOpt(Channel.LOCAL, Boolean.FALSE);
        return newChannel(name, mc);
    }
    
    private void setLocalAddress(JChannel parent, JChannel mux) throws Exception {
        // local_addr Needs to be set, unless the "Ignore local messages" feature would not work.
        Field f = org.jgroups.JChannel.class.getDeclaredField("local_addr");
        f.setAccessible(true);
        f.set(mux, parent.getLocalAddress());
    }
    
    private JChannel newChannel(final String id, final JChannel c1) throws Exception
    {
        c1.setReceiver(new ReceiverAdapter() {
            @Override
            public void receive(Message msg) {
                super.receive(msg);
                System.out.println(id + " Received message: " + msg + " msg: " + msg.getObject());
            }
            @Override
            public void viewAccepted(View new_view) {
//                try {
//                    Thread.sleep((int)(Math.random()*1000.0));
//                } catch (InterruptedException e) {
//                    throw new RuntimeException(e);
//                }
//                System.out.println(id + " New View (new_view): " + new_view);
//                System.out.println(id + " New View (Channel):  " + c1.getView());
            }
        });
        return c1;
    }
    
    private Element getConfig() throws Exception {
        String config = 
            "<config>                                                                           " +
            "  <UDP mcast_recv_buf_size=\"80000\" mcast_send_buf_size=\"150000\"                " +
            "      mcast_port=\"32233\" mcast_addr=\"228.0.0.1\"                                " +
            "      ip_ttl=\"32\"/>                                                              " +
            "  <PING/>                                                                          " +
            "  <FD_SOCK/>                                                                       " +
            "  <VERIFY_SUSPECT timeout=\"15000\"/>                                               " +
            "  <pbcast.NAKACK gc_lag=\"50\" retransmit_timeout=\"300,600,1200,2400,48000\"/>     " +
            "  <UNICAST timeout=\"600,1200,2000,25000\"/>                                        " +
            "  <FRAG frag_size=\"8096\"/>                                                       " +
            "  <pbcast.STABLE desired_avg_gossip=\"20000\" max_bytes=\"500000\"/>               " +
            "  <pbcast.GMS print_local_addr=\"true\" join_timeout=\"60000\" shun=\"true\" />     " +
            "</config>                                                                          ";
        
        DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
        DocumentBuilder db = dbf.newDocumentBuilder();
        Document d = db.parse(new ByteArrayInputStream(config.getBytes()));
        return d.getDocumentElement();
    }
}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 11:56:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Mon, 15 Jun 2009 11:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13775671.1245081416919.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBWEB-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472123#action_12472123 ] 

Mike Millson commented on JBWEB-144:
------------------------------------

Cummulative change set for this patch 6.0.13 --> 6.0.19:
562807
658470
677728
677729
685699
685701
685708
698887
698913
698918
714256

Based on changes for individual affected files 6.0.13 --> 6.0.19:
========================================
1) ELParser.jtt:
658470
677728
685699
685701
698887
698913
698918
714256

2) ELParser.java:
562807
658470
677729
685708
698918
714256 

3) ELParserConstants.java:
562807
658470
677729
685708
714256 

4) ELParserTokenManger.java:
562807
658470
677729
685708
714256

> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 12:18:56 2009
From: jira-events at lists.jboss.org (Marco Ghanitab (JIRA))
Date: Mon, 15 Jun 2009 12:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2123) issue with the
 call of a drl function
Message-ID: <1390184.1245082736749.JavaMail.jira@cloud.prod.atl2.jboss.com>

issue with the call of a drl function
-------------------------------------

                 Key: JBRULES-2123
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2123
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Marco Ghanitab
            Assignee: Mark Proctor
            Priority: Minor


in a drl file with a rule "reset" ad a function "formatDate",a bad behaviour is verified when is called the function in the "when" block..it call the function many times, but if the function called is stored in a external java file (not drl) everything works fine, and it call the function only 2 times (correct).
Here the code of the drl file:


rule "reset"
        when
                $conversation:Conversation(resource.code == "sms", tickets.size > 0)
                not Discount(date == (formatDate($conversation.getStopDate())))
        then 
                Discount discount = new Discount();
                discount.setDate(formatDate($conversation.getStopDate()));
                discount.setQuantity(495);
                insert(discount);               
                System.out.println("reset " + discount.getDate());
end
 
declare Discount
   date : String
   quantity : int
end
 
function String formatDate(java.util.Date date) {
        java.text.SimpleDateFormat formatter = new java.text.SimpleDateFormat("dd/MM/yy");
        return formatter.format(date);
}




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 12:23:07 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 15 Jun 2009 12:23:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBVFS-114) Abstract zip reading
Message-ID: <20028343.1245082987027.JavaMail.jira@cloud.prod.atl2.jboss.com>

Abstract zip reading
--------------------

                 Key: JBVFS-114
                 URL: https://jira.jboss.org/jira/browse/JBVFS-114
             Project: JBoss VFS
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.2.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: 2.2.0.Alpha


Zip reading should be abstracted in order to be able to plug in other reader implementations.
e.g. DML' jzipfile or truezip

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 12:26:56 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Mon, 15 Jun 2009 12:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7023) Web Beans
 integration points container task
Message-ID: <1066442.1245083216361.JavaMail.jira@cloud.prod.atl2.jboss.com>

Web Beans integration points container task
-------------------------------------------

                 Key: JBAS-7023
                 URL: https://jira.jboss.org/jira/browse/JBAS-7023
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Web Beans
            Reporter: Pete Muir
            Assignee: Pete Muir
             Fix For: JBossAS-5.2.0.Beta1


Container task for Web Beans integration tasks to allow JBoss AS to fully pass TCK

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 12:28:56 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Mon, 15 Jun 2009 12:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7023) Web Beans
 integration points container task
In-Reply-To: <1066442.1245083216361.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10541917.1245083336485.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472136#action_12472136 ] 

Pete Muir commented on JBAS-7023:
---------------------------------

Once a component upgrade task is created, we need to add a upgrade Javassist 3.11.0 task.

> Web Beans integration points container task
> -------------------------------------------
>
>                 Key: JBAS-7023
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7023
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Beans
>            Reporter: Pete Muir
>            Assignee: Pete Muir
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Container task for Web Beans integration tasks to allow JBoss AS to fully pass TCK

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 12:45:09 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Mon, 15 Jun 2009 12:45:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17035648.1245084309063.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-144:
-------------------------------

    Comment: was deleted


> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 12:45:08 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Mon, 15 Jun 2009 12:45:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13415378.1245084308839.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBWEB-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472140#action_12472140 ] 

Mike Millson commented on JBWEB-144:
------------------------------------

Cummulative change set for this patch 6.0.13 --> 6.0.19:
562807
578466
578610
658470
607334
649195
677728
677729
685699
685701
685708
698887
698913
698918
714256

Based on changes for individual affected files 6.0.13 --> 6.0.19:
========================================
1) ELParser.jtt:
658470
677728
685699
685701
698887
698913
698918
714256

2) ELParser.java:
562807
658470
677729
685708
698918
714256

3) ELParserConstants.java:
562807
658470
677729
685708
714256

4) ELParserTokenManger.java:
562807
658470
677729
685708
714256

5) EvaluationContext.java
607334
698887

6) FunctionMapperImpl.java
578466
578610
649195
698887

> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 13:31:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 15 Jun 2009 13:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7010)
 JndiLoginInitialContextFactory is
 not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18739028.1245087116560.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7010:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 13:47:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 15 Jun 2009 13:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18935442.1245088076659.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472163#action_12472163 ] 

Ian Springer commented on JBAS-7008:
------------------------------------

I've deployed an EJB3 entity bean, and the corresponding MBean in the jmx-console (jboss.j2ee:jar=entity-test.jar,name=EntityTestBean,service=EJB3) contains the following metrics:

CreateCount  	R  	int  	MBean Attribute.  	
InvokeStats 	R 	org.jboss.ejb3.statistics.InvocationStatistics 	MBean Attribute. 	
CurrentSize 	R 	int 	MBean Attribute. 	
RemoveCount 	R 	int 	MBean Attribute. 	
MaxSize 	R 	int 	MBean Attribute. 	
AvailableCount    R   int   MBean Attribute. 	

Can we expose these same metrics via the Entity Bean ManagedObject?


> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 13:49:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Mon, 15 Jun 2009 13:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6939) after stopping a
 Topic or Queue
 via the stop operation, calling getRunState() on the corresponding
 component returns RunState.RUNNING, rather than RunState.STOPPED
In-Reply-To: <3464546.1242671225528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9140947.1245088196600.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved JBAS-6939.
---------------------------------------

    Resolution: Done


> after stopping a Topic or Queue via the stop operation, calling getRunState() on the corresponding component returns RunState.RUNNING, rather than RunState.STOPPED
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6939
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6939
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Ian Springer
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 14:05:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 15 Jun 2009 14:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-34) Container Task:
 Formalize Kerberos offering
In-Reply-To: <33197347.1173287004217.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21141583.1245089156752.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-34.
---------------------------------

    Resolution: Done


JBoss Negotiation does an awesome job.

use it standalone - or as part of JBAS5.1.0++

> Container Task: Formalize Kerberos offering
> -------------------------------------------
>
>                 Key: SECURITY-34
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-34
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 1.x, 2.0.GA
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: NO_VERSION
>
>
> Spoken to Chris Delashmutt about formalizing the initial work he did for Kerberos/spnego.
> http://wiki.jboss.org/wiki/Wiki.jsp?page=NegotiateKerberos
> This jira task is a container task for overall kerberos silent authentication tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 14:19:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Mon, 15 Jun 2009 14:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6753219.1245089996749.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-144:
-------------------------------

    Attachment: jbweb-144.patch


Proposed CP branch patch from this chain of patches:
1) svn diff -r 562806:562807 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 562807.patch
2) svn diff -r 578465:578466 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 578466.patch
3) svn diff -r 578609:578610 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 578610.patch
4) svn diff -r 607333:607334 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 607334.patch
5) svn diff -r 649194:649195 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 649195.patch
6) svn diff -r 658469:658470 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 658470.patch
7) svn diff -r 677727:677728 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 677728.patch
8) svn diff -r 677728:677729 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 677729.patch
9) svn diff -r 685698:685699 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 685699.patch
10) svn diff -r 685700:685701 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 685701.patch
11) svn diff -r 685707:685708 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 685708.patch
12) svn diff -r 698886:698887 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 698887.patch
13) svn diff -r 698912:698913 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 698913.patch
14) svn diff -r 698917:698918 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 698918.patch
15) svn diff -r 714255:714256 http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ > 714256.patch

Would it be better, given the extent of changes, to rebase some part of the code (e.g. org.apache.el) to 6.0.19?

> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-144.patch, test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 14:25:56 2009
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 15 Jun 2009 14:25:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32668632.1245090356513.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBWEB-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472170#action_12472170 ] 

Remy Maucherat commented on JBWEB-144:
--------------------------------------

Yes, EL got fixed, then refixed, then rerefixed. As the package is quite self contained, rebasing should be easy.

> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-144.patch, test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 15:20:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 15 Jun 2009 15:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-415) ClientLoginModule
 multi-threaded=false should make SecurityContext
 client side association
In-Reply-To: <12517767.1244524256604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31035966.1245093656926.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-415.
----------------------------------

    Resolution: Done


> ClientLoginModule multi-threaded=false should make SecurityContext client side association
> ------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-415
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-415
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.3.SP1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: 2.0.3.SP2
>
>
> The ClientLoginModule multi-threaded=false option when missing, should set SecurityContextAssociation.setClient()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 15:27:57 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Mon, 15 Jun 2009 15:27:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18989079.1245094077346.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-142:
-------------------------------

    Attachment: jbweb-142.patch


Proposed patch for CP branch. Let me know if this is acceptable.

Do we want to put this anywhere upstream (e.g. trunk, 2.1.x branch, etc.)?

> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-142.patch
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 16:29:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Mon, 15 Jun 2009 16:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREFLECT-3) Use an appropriate
 Javassist ClassPool
In-Reply-To: <12331947.1165415635891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3767544.1245097796718.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBREFLECT-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone updated JBREFLECT-3:
-----------------------------------

        Summary: Use an appropriate Javassist ClassPool  (was: Use the ScopedClassPool from javassist)
    Description: 
The javassist reflection utilities use the original shared classpool.
This does not understand classloaders.

This should be updated to use a more appropriate ClassPool.

Good starting points are the  ScopedClassPool from Javassist and the ClassPools from JBossAOP (check AOPClassPool and ClassPool implementations at jboss-aop-asintegration-* subprojects.

  was:
The javassist reflection utilities use the original shared classpool.
This does not understand classloaders.

This should be updated to use the newer ScopedClassPool from javassist.



> Use an appropriate Javassist ClassPool
> --------------------------------------
>
>                 Key: JBREFLECT-3
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-3
>             Project: JBoss Reflection
>          Issue Type: Task
>          Components: Javassist
>            Reporter: Adrian Brock
>            Assignee: Flavia Rainone
>
> The javassist reflection utilities use the original shared classpool.
> This does not understand classloaders.
> This should be updated to use a more appropriate ClassPool.
> Good starting points are the  ScopedClassPool from Javassist and the ClassPools from JBossAOP (check AOPClassPool and ClassPool implementations at jboss-aop-asintegration-* subprojects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 16:31:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Mon, 15 Jun 2009 16:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREFLECT-3) Use an appropriate
 Javassist ClassPool
In-Reply-To: <12331947.1165415635891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28668132.1245097916663.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBREFLECT-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone updated JBREFLECT-3:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237746


> Use an appropriate Javassist ClassPool
> --------------------------------------
>
>                 Key: JBREFLECT-3
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-3
>             Project: JBoss Reflection
>          Issue Type: Task
>          Components: Javassist
>            Reporter: Adrian Brock
>            Assignee: Flavia Rainone
>
> The javassist reflection utilities use the original shared classpool.
> This does not understand classloaders.
> This should be updated to use a more appropriate ClassPool.
> Good starting points are the  ScopedClassPool from Javassist and the ClassPools from JBossAOP (check AOPClassPool and ClassPool implementations at jboss-aop-asintegration-* subprojects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 16:46:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Mon, 15 Jun 2009 16:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREFLECT-54) Implement the
 Expression Interfaces
Message-ID: <3249894.1245098816505.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement the Expression Interfaces
-----------------------------------

                 Key: JBREFLECT-54
                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-54
             Project: JBoss Reflection
          Issue Type: Task
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone


The expressio interfaces should be implemented, allowing instrumentation of "Javassist expressions" through JBoss Reflection API.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 21:13:56 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Mon, 15 Jun 2009 21:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-4)
 AnnotationMergedView ignores
 annotated beans when xml does not define beans
In-Reply-To: <32782915.1200391879117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25747956.1245114836981.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472245#action_12472245 ] 

Richard Kennard commented on JBMETA-4:
--------------------------------------

Please note, as of the version of JBoss Metadata shipped with JBoss 5.1.0.GA:

You see this 'JBMETA-4' warning (and your annotated beans do not properly deploy) if you forget to put proper namespaces on the ejb-jar.xml. It should be...

<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">

...not just...

<ejb-jar>



> AnnotationMergedView ignores annotated beans when xml does not define beans
> ---------------------------------------------------------------------------
>
>                 Key: JBMETA-4
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-4
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.0.Beta5
>            Reporter: Carlo de Wolf
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>             Fix For: 1.0.0.Beta6
>
>
> AnnotationMergedView.merge(EnterpriseBeansMetaData merged, EnterpriseBeansMetaData xml, EnterpriseBeansMetaData annotation)
> falls through without doing anything if xml is null.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 15 22:29:08 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 15 Jun 2009 22:29:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22082632.1245119348362.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7008:
-------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Complexity: Low


> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 02:49:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 16 Jun 2009 02:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-991) ReceiveLocalMessages
 does not work on MuxChannel
In-Reply-To: <22126121.1245079437238.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28006364.1245134996565.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban closed JGRP-991.
-------------------------

    Resolution: Won't Fix


Hi Stefan,

thanks for the bug report and test case ! However, as the Multiplexer has been deprecated and is not supported any longer, we won't fix this bug. Multiplexer will be removed in 3.0, use a shared transport instead.

If you absolutely need to use the Multiplexer in 2.6.x, reopen this issue and attach a patch, which I'll then apply.

> ReceiveLocalMessages does not work on MuxChannel
> ------------------------------------------------
>
>                 Key: JGRP-991
>                 URL: https://jira.jboss.org/jira/browse/JGRP-991
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.10
>         Environment: RHEL4 Linux/Windows XP
>            Reporter: Stefan Anzinger
>            Assignee: Bela Ban
>
> Setting receive local messages to false does not work on Multiplex Channels. Reason for this is, that the local_addr is not set on multiplex channels - therefore the mux channel cannot decide whether this message comes from local or not.
> See attached a small testcase. The testcase just gets the local_addr from the "physical channel" and puts it into the MuxChannel local_addr via reflection.
> Here is the testcase:
> import java.io.ByteArrayInputStream;
> import java.lang.reflect.Field;
> import org.w3c.dom.*;
> import javax.xml.parsers.*;
> import junit.framework.TestCase;
> import org.jgroups.*;
> import org.jgroups.mux.Multiplexer;
> public class TestJGroups extends TestCase {
>     /**
>      * Tests the receiveLocalMessages feature on multiplex
>      * channels.
>      * 
>      * <h2>Course of action</h2>
>      * <ol>
>      *   <li>Creates tow physical channels</li>
>      *   <li>For each physical channel a mux channel is created</li>
>      *   <li>Receive Local messages is turned off on the mux channels</li>
>      *   <li>Local address has to be set manually after connecting the physical channels (This may be done automatically)</li>
>      *   <li>Message is sent from the first mux to the second mux channel</li>
>      * </ol>
>      * 
>      * @throws Exception
>      */
>     public void testMultiplex() throws Exception {
>         JChannelFactory factory = new JChannelFactory(getConfig());
>         JChannel c1 = newChannel("c1", (JChannel)factory.createChannel());
>         JChannel c2 = newChannel("c2", (JChannel)factory.createChannel());
>         JChannel mc1 = newMuxChannel(c1, "mc1");
>         JChannel mc2 = newMuxChannel(c2, "mc2");
>         mc1.setOpt(Channel.LOCAL, Boolean.FALSE);
>         mc2.setOpt(Channel.LOCAL, Boolean.FALSE);
>         mc1.connect("X");
>         mc2.connect("Y");
>         // By commenting this, the messages are also received locally
>         setLocalAddress(c1, mc1);   
>         setLocalAddress(c2, mc2);
>         
>         Thread.sleep(2000);
>         
>         mc1.send(new Message(null, null, "HELLO WORLD"));
>         
>         Thread.sleep(500);
>         
>         c2.disconnect();
>         c1.disconnect();
>     }
>     
>     private JChannel newMuxChannel(JChannel channel, String name) throws Exception {
>         Multiplexer mux = new Multiplexer(channel);
>         JChannel mc = (JChannel)mux.createMuxChannel("hello1", "ASDF2");
>         
>         mc.setOpt(Channel.LOCAL, Boolean.FALSE);
>         return newChannel(name, mc);
>     }
>     
>     private void setLocalAddress(JChannel parent, JChannel mux) throws Exception {
>         // local_addr Needs to be set, unless the "Ignore local messages" feature would not work.
>         Field f = org.jgroups.JChannel.class.getDeclaredField("local_addr");
>         f.setAccessible(true);
>         f.set(mux, parent.getLocalAddress());
>     }
>     
>     private JChannel newChannel(final String id, final JChannel c1) throws Exception
>     {
>         c1.setReceiver(new ReceiverAdapter() {
>             @Override
>             public void receive(Message msg) {
>                 super.receive(msg);
>                 System.out.println(id + " Received message: " + msg + " msg: " + msg.getObject());
>             }
>             @Override
>             public void viewAccepted(View new_view) {
> //                try {
> //                    Thread.sleep((int)(Math.random()*1000.0));
> //                } catch (InterruptedException e) {
> //                    throw new RuntimeException(e);
> //                }
> //                System.out.println(id + " New View (new_view): " + new_view);
> //                System.out.println(id + " New View (Channel):  " + c1.getView());
>             }
>         });
>         return c1;
>     }
>     
>     private Element getConfig() throws Exception {
>         String config = 
>             "<config>                                                                           " +
>             "  <UDP mcast_recv_buf_size=\"80000\" mcast_send_buf_size=\"150000\"                " +
>             "      mcast_port=\"32233\" mcast_addr=\"228.0.0.1\"                                " +
>             "      ip_ttl=\"32\"/>                                                              " +
>             "  <PING/>                                                                          " +
>             "  <FD_SOCK/>                                                                       " +
>             "  <VERIFY_SUSPECT timeout=\"15000\"/>                                               " +
>             "  <pbcast.NAKACK gc_lag=\"50\" retransmit_timeout=\"300,600,1200,2400,48000\"/>     " +
>             "  <UNICAST timeout=\"600,1200,2000,25000\"/>                                        " +
>             "  <FRAG frag_size=\"8096\"/>                                                       " +
>             "  <pbcast.STABLE desired_avg_gossip=\"20000\" max_bytes=\"500000\"/>               " +
>             "  <pbcast.GMS print_local_addr=\"true\" join_timeout=\"60000\" shun=\"true\" />     " +
>             "</config>                                                                          ";
>         
>         DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
>         DocumentBuilder db = dbf.newDocumentBuilder();
>         Document d = db.parse(new ByteArrayInputStream(config.getBytes()));
>         return d.getDocumentElement();
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 02:51:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 16 Jun 2009 02:51:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-992) JChannelFactory:
	remove
Message-ID: <24627559.1245135116701.JavaMail.jira@cloud.prod.atl2.jboss.com>

JChannelFactory: remove
-----------------------

                 Key: JGRP-992
                 URL: https://jira.jboss.org/jira/browse/JGRP-992
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.0


Users should inject a channel via other means than a JChannelFactory. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 03:33:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 16 Jun 2009 03:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-89) The parent of a
 ManagedComponent should be it's defining ManagedObject
Message-ID: <19872504.1245137636613.JavaMail.jira@cloud.prod.atl2.jboss.com>

The parent of a ManagedComponent should be it's defining ManagedObject
----------------------------------------------------------------------

                 Key: JBMAN-89
                 URL: https://jira.jboss.org/jira/browse/JBMAN-89
             Project: JBoss Managed
          Issue Type: Task
    Affects Versions: JBossMan.2.1.1.Beta3
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber
             Fix For: JBossMan.2.0.1.CR1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 03:38:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 16 Jun 2009 03:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-89) The parent of a
 ManagedComponent should be it's defining ManagedObject
In-Reply-To: <19872504.1245137636613.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29450509.1245137936439.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMAN-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved JBMAN-89.
--------------------------------------

    Resolution: Done


> The parent of a ManagedComponent should be it's defining ManagedObject
> ----------------------------------------------------------------------
>
>                 Key: JBMAN-89
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-89
>             Project: JBoss Managed
>          Issue Type: Task
>    Affects Versions: JBossMan.2.1.1.Beta3
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossMan.2.0.1.CR1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 04:17:00 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?J=C3=BCrgen_Schiewe_=28JIRA=29?=)
Date: Tue, 16 Jun 2009 04:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2124) KnowledgeAgent
 should load
 knowledge bases directly from Resource (bypassing the ChangeSet)
Message-ID: <29623001.1245140220703.JavaMail.jira@cloud.prod.atl2.jboss.com>

KnowledgeAgent should load knowledge bases directly from Resource (bypassing the ChangeSet)
-------------------------------------------------------------------------------------------

                 Key: JBRULES-2124
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2124
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-api, drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: J?rgen Schiewe
            Assignee: Mark Proctor


We develop Drools based applications and use Guvnor as a a repository. Hard-coding the hostname where Guvnor runs is not an option for us because the names are different in each installation and we do not want to modify all the changeset.xml files for each deployment.

Instead we would pass one (or more) Resources to the KnowledgeAgent and let it do the monitoring. This would allow us to build URLs dynamically from our system environment configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Tue Jun 16 05:47:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Tue, 16 Jun 2009 05:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2125) Drools core
 multithreading issue
In-Reply-To: <26229278.1245145676528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <778684.1245145676733.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrey Nechaev updated JBRULES-2125:
------------------------------------

    Attachment: Main.java


Here is the attachement

> Drools core multithreading issue
> --------------------------------
>
>                 Key: JBRULES-2125
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2125
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: Java HotSpot v 1.6.0_06, WinXP SP3
>            Reporter: Andrey Nechaev
>            Assignee: Mark Proctor
>         Attachments: Main.java
>
>
> Attachement below is the code showing the problems. 
> The program hangs and nothing is displayed in the Console.
> If I put lines 10-11 before the line 6, I get a NullPointerException:
> Exception in thread "main" java.lang.NullPointerException
>             at org.drools.reteoo.ObjectSource.addObjectSink(ObjectSource.java:124)
> ...
> But, if I comment out the lines 2&3, everything works ok.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 05:47:56 2009
From: jira-events at lists.jboss.org (Andrey Nechaev (JIRA))
Date: Tue, 16 Jun 2009 05:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2125) Drools core
 multithreading issue
Message-ID: <26229278.1245145676528.JavaMail.jira@cloud.prod.atl2.jboss.com>

Drools core multithreading issue
--------------------------------

                 Key: JBRULES-2125
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2125
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
         Environment: Java HotSpot v 1.6.0_06, WinXP SP3
            Reporter: Andrey Nechaev
            Assignee: Mark Proctor
         Attachments: Main.java

Attachement below is the code showing the problems. 

The program hangs and nothing is displayed in the Console.

If I put lines 10-11 before the line 6, I get a NullPointerException:

Exception in thread "main" java.lang.NullPointerException
            at org.drools.reteoo.ObjectSource.addObjectSink(ObjectSource.java:124)
...

But, if I comment out the lines 2&3, everything works ok.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 06:19:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 16 Jun 2009 06:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1850) Synchronizations
 registered on the tx depend on ordering
Message-ID: <4600779.1245147596442.JavaMail.jira@cloud.prod.atl2.jboss.com>

Synchronizations registered on the tx depend on ordering
--------------------------------------------------------

                 Key: EJBTHREE-1850
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1850
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf
            Priority: Critical
             Fix For: EAP 5




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 08:17:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 16 Jun 2009 08:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7017) Upgrade EJB3 to
	1.1.7
In-Reply-To: <8087911.1245054716478.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26416044.1245154676611.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-7017.
--------------------------------

    Resolution: Done


Done. r90248.

Note: The upgrade was partially done already when EJB3 1.1.8-Alpha1 was introduced into the component-matrix through a separate commit.

> Upgrade EJB3 to 1.1.7
> ---------------------
>
>                 Key: JBAS-7017
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7017
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> EJB3 1.1.7 version has been released. Update the AS to use this new version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 08:19:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 16 Jun 2009 08:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7018) Upgrade EJB3 to
	1.1.7
In-Reply-To: <25050850.1245054836512.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6975052.1245154796724.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472311#action_12472311 ] 

jaikiran pai commented on JBAS-7018:
------------------------------------

The integration of EJB3 1.1.7 with AS trunk, hasn't yet been centrally tested on Hudson because of build issue http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157046

Once we test the release centrally on hudson, will upgrade the component-matrix appropriately.


> Upgrade EJB3 to 1.1.7
> ---------------------
>
>                 Key: JBAS-7018
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7018
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Update the AS to use the newly released EJB3 1.1.7 version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 08:19:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 16 Jun 2009 08:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2125) Drools core
 multithreading issue
In-Reply-To: <26229278.1245145676528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22852376.1245154796951.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned JBRULES-2125:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> Drools core multithreading issue
> --------------------------------
>
>                 Key: JBRULES-2125
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2125
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: Java HotSpot v 1.6.0_06, WinXP SP3
>            Reporter: Andrey Nechaev
>            Assignee: Edson Tirelli
>         Attachments: Main.java
>
>
> Attachement below is the code showing the problems. 
> The program hangs and nothing is displayed in the Console.
> If I put lines 10-11 before the line 6, I get a NullPointerException:
> Exception in thread "main" java.lang.NullPointerException
>             at org.drools.reteoo.ObjectSource.addObjectSink(ObjectSource.java:124)
> ...
> But, if I comment out the lines 2&3, everything works ok.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 08:21:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 16 Jun 2009 08:21:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1946) Deserializing a
 KnowledgeBase object throws a java.io.EOFException
In-Reply-To: <13586666.1233155564971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9209299.1245154917307.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472312#action_12472312 ] 

Edson Tirelli commented on JBRULES-1946:
----------------------------------------

Adding additional info by the user:

==============
Hello Rick,

I confirm, that implementations - DroolsObjectOutputStream and DroolsObjectInputStream work well, but it's not applicable in my case, because I depend on external component, that is responsible for storing my data and it uses standard serialization mechanisms. Of course, I may do some workarounds that for example first serialize the stream using Drools implementation and then pass it to the external component, but I prefer to try to do it as it should be. If I don't manage to, I will think about some other ways.

Anyway, thank you for your response and advice.

Best regards,
Przemys?aw R??ycki


> Deserializing a KnowledgeBase object throws a java.io.EOFException
> ------------------------------------------------------------------
>
>                 Key: JBRULES-1946
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1946
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions:  5.0.0.M4, 5.0.0.M5
>         Environment: Ubuntu 8.10
>            Reporter: Simon Kelly
>            Assignee: Edson Tirelli
>             Fix For: 5.0.1.FINAL
>
>         Attachments: drools.test.zip, DroolsTest.java, Sample.drl, Sample1.drl, Sandbox2.java
>
>
> A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file.
> java.io.EOFException
> 	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
> 	at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
> 	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
> 	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55)
> 	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49)
> 	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227)
> 	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173)
> 	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83)
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at com.sample.DroolsTest.read(DroolsTest.java:75)
> 	at com.sample.DroolsTest.testIO(DroolsTest.java:50)
> 	at com.sample.DroolsTest.main(DroolsTest.java:40)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Tue Jun 16 08:58:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 16 Jun 2009 08:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-193) Provide a extended
 DeploymentVisitor which can be used for filtering out deployers
Message-ID: <10118475.1245157136971.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide a extended DeploymentVisitor which can be used for filtering out deployers
----------------------------------------------------------------------------------

                 Key: JBDEPLOY-193
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-193
             Project: JBoss Deployers
          Issue Type: Feature Request
          Components: deployer
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: jaikiran pai
            Assignee: jaikiran pai


The AbstractRealDeployerWithInput currently relies on a DeploymentVisitor for filtering out deployers while processing out a deployment unit. The DeploymentVisitor is responsible for specifying the "type" of attachment to  look for, in the unit, to decide whether the unit can be processed by the deployer. There are 2 short-comings with the current DeploymentVisitor:

1) A unit can have multiple attachments of the same type - This effectively means a deployer cannot specify which out of these n attachments, is it interested in. This results in the deployer being called multiple times for the same unit.

2) Because the AbstractRealDeployerWithInput relies on the type of the attachment, it is expensive:

protected <U> void deploy(DeploymentUnit unit, DeploymentVisitor<U> visitor) throws DeploymentException
   {
      if (visitor == null)
         throw new IllegalArgumentException("Null visitor.");

      List<U> visited = new ArrayList<U>();
      try
      {
         Set<? extends U> deployments = unit.getAllMetaData(visitor.getVisitorType());
...

unit.getAllMetaData internally iterates over all attachments to create collection of eligible attachments.

To improve this, an ExtendedDeploymentVisitor can be introduced which allows for a deployer to register itself for a specific attachment with name and the corresponding type of the attachment. A new deployer can then use this ExtendedDeploymentVisitor to efficiently process the deployment unit.
 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 09:24:57 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 16 Jun 2009 09:24:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-5417) Deployment from a
 Restarted
 Nodes(after Crash/Shutdown) in a Cluster does not Hot Deploys.
Message-ID: <21131664.1245158697323.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated JBAS-5417:
-------------------------------

    Assignee: Scott Marlow  (was: Scott Marlow)


> Deployment from a Restarted Nodes(after Crash/Shutdown) in a Cluster does not Hot Deploys.
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-5417
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5417
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: JBoss 4.0.2 running on Redhat enterprise Linux 2.4.21-15
>            Reporter: Hari Prasad Kuppuswamy
>            Assignee: Scott Marlow
>             Fix For: Backlog
>
>
> Hai, 
> I am currently using JBoss 4.0.2 and facing a problem with Cluster Hot Deployment with restarted nodes. 
> I have only two nodes,say NODE-1 & NODE-2 in my Cluster. 
> 1.Intially,two nodes are running with EAR deployed on them. 
> 2.Suddenly,NODE-2 Crashes and is shutdown. 
> 3.Now,NODE-2 is restarted after sometime & when it starts,it gets hot deployed. 
> Fine until now..... 
> 4.But when I undeploy EAR from NODE-2,NODE-1 also gets undeployed accordingly. 
> 5.So now when I redeploy the EAR from NODE-2,NODE-2 gets deployed but NODE-1 is not getting hot deployed. 
> Note:But when I do Step 5 from NODE-1 and deploy EAR from NODE-1,it gets hot deployed accross NODE-2. 
> Now Further ..... 
> Instead of the Step 4,5 above,consider the following scenario. 
> 4.Now,Node 1 also crashes and recovers after some time. 
> 5.So both the nodes are now in a restarted state in Cluster.When I undeploy EAR from NODE-2 or NODE-1,both the nodes gets undeployed accordingly. 
> 6.But now when I redeploy from any of the restarted NODE-1 or NODE-2,it does not get hot deployed.Only the node from which I deploy gets deployed.
>    I think that this is a critical path in a Production Environment. 
> Thanks, 
> Hari 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 09:24:59 2009
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 16 Jun 2009 09:24:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2126) Simulation and
 testing framwork
Message-ID: <24807269.1245158699830.JavaMail.jira@cloud.prod.atl2.jboss.com>

Simulation and testing framwork
-------------------------------

                 Key: JBRULES-2126
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2126
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-core
            Reporter: Mark Proctor
            Assignee: Mark Proctor
             Fix For: 5.1.0.M1


Api for full simulation and testing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 09:24:58 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 16 Jun 2009 09:24:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3023) Bad interaction
 between farming/ha proxies
Message-ID: <21249517.1245158698498.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated JBAS-3023:
-------------------------------

    Assignee: Scott Marlow  (was: Scott Marlow)


> Bad interaction between farming/ha proxies
> ------------------------------------------
>
>                 Key: JBAS-3023
>                 URL: https://jira.jboss.org/jira/browse/JBAS-3023
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Deployers
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>            Assignee: Scott Marlow
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> At least two forum thread indicate there is a problem with farmed deployments breaking ha proxy behavior when one application is undeployed:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=80011
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77986

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 09:24:59 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 16 Jun 2009 09:24:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCLUSTER-67) Proposal for new
 FarmMemberSingletonService
Message-ID: <13784767.1245158699472.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBCLUSTER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated JBCLUSTER-67:
----------------------------------

    Assignee: Scott Marlow  (was: Scott Marlow)


> Proposal for new FarmMemberSingletonService
> -------------------------------------------
>
>                 Key: JBCLUSTER-67
>                 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-67
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: Q4Y5
>         Environment: Jboss 4.0.3RC2
>            Reporter: Gabriele Garuglieri
>            Assignee: Scott Marlow
>            Priority: Minor
>         Attachments: FarmMemberSingletonService-withSync.zip, FarmMemberSingletonService.zip
>
>
> Here is the proposal for a new service that behaves like FarmMemberService for the farming part, but  deploys files only on one node of the cluster.
> It has the following features:
> 1- it is obtained extending org.jboss.ha.framework.server.FarmMemberService
> 2- since the hierarchy org.jboss.deployment.scanner.URLDeploymentScanner, org.jboss.ha.framework.server.FarmMemberService was not extendable without pratically duplicating all the scanner code or entering in an "if, if, if..." nightmare i thought to refactor both classes to allow easy extendability.
> 3- it is associated with org.jboss.ha.singleton.HASingletonController which controls the singleton activation in only one node of the cluster.
> 4- in the nodes where the singleton is stopped it simply farms  files in the controlled directories keeping them up to date with the other nodes
> 5- in the node where the singleton is started it behaves exactly like FarmMemberService
> 6- the singleton is always started in the first started node (HASingletonController behaviour)
> 7- if the active node is stopped the singleton is activated in the next node in startup order
> 8- the singleton may be stopped by stopping its controller (from web console) without shutting down the server and will be automatically activated in the next node in startup order
> 9- when the singleton is stopped without shutting down the node it immediately undeploys all the files and keeps the farming function active, the files will be deployed in the next  node where the singleton is started
> 10- if the singleton, stopped from console, is restarted in a node first in startup order than the node where the the service was restarted, it stops the service in the other node regaining its master status (HASingletonController behaviour)
> 11- while refactoring i introduced a small change in FarmMemberService behaviour: the scanner is now run before calling pullNewDeployments() so  this method is now able to check if files are up to date with coordinator node avoiding to always transfer files even when they are the same as those in coordinator node. For the rest the behaviour of both URLDeploymentScanner and FarmMemberService is not changed
> 12- while testing i corrected a couple of problems in org.jboss.ha.framework.server.ClusterFileTransfer.push():
> - the first is that the remotePushWriteFile procedure  is always called and when the cluster has only one active node this mean a lot useless work for each deployed file, this is bad overhead for large files. I introduced a control so that the push() proceeds only if the cluster has at least two nodes
> - the second is a real bug, the input.close() is missing and this in Windows systems locks the deployed files not allowing any longer to overwrite or delete them until the server is closed
> I hope this is accepted, because i plan to use it in my production env and i'd like to see it in official release
> Gabriele

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 09:24:58 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 16 Jun 2009 09:24:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-5416) An application that
 is "farm"
 undeployed from the cluster could come back into the cluster.
Message-ID: <16852087.1245158698769.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated JBAS-5416:
-------------------------------

    Assignee: Scott Marlow  (was: Scott Marlow)


> An application that is "farm" undeployed from the cluster could come back into the cluster.
> -------------------------------------------------------------------------------------------
>
>                 Key: JBAS-5416
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5416
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.0.GA, JBossAS-4.2.1.GA, JBossAS-4.2.2.GA
>         Environment: any
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: Backlog
>
>
> An application that is "farm" undeployed from the cluster could come back into the cluster.  Steps to reproduce:
> a. Create a cluster with more than one node.  Lets assume three server nodes named { node1, node2, node3 }
> b.  Deploy an application to the cluster, I used WineDemo.war.
> c.  Bring node3 down.
> d.  Delete WineDemo.war from the cluster.  Note that it didn't get deleted from node3's farm folder as node3 is down.
> e.  Bring node3 back up, WineDemo.war is still running on node3.
> The workaround for this issue is to manually remove WineDemo.war from node3 before bringing it back up.
> A secondary problem occurs you then bring node2 down and back up.  We will deploy WineDemo.war on node2 (pulled from node3).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 09:36:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 16 Jun 2009 09:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-990) Grammatical Error in
 log message: I'm being am suspected.
In-Reply-To: <15502315.1244833736783.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26696178.1245159416742.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-990.
---------------------------

    Resolution: Done


> Grammatical Error in log message: I'm being am suspected.
> ---------------------------------------------------------
>
>                 Key: JGRP-990
>                 URL: https://jira.jboss.org/jira/browse/JGRP-990
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.1
>         Environment: N/A
>            Reporter: Duane Olawsky
>            Assignee: Bela Ban
>            Priority: Trivial
>             Fix For: 2.4.7
>
>
> There is a grammatical error in the following log message:
> "WARN - I am the coord and I'm being am suspected -- will probably leave shortly"
> I suggest removing the second "am".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 10:04:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 16 Jun 2009 10:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-532) Ant tasks not
 passing properties correctly to AS dist build
Message-ID: <17089570.1245161096601.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ant tasks not passing properties correctly to AS dist build
-----------------------------------------------------------

                 Key: JBBUILD-532
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-532
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven Builds
            Reporter: Paul Gier
            Assignee: Paul Gier
             Fix For: Maven Build - Maint 2009


There is a problem passing properties through the antrun plugin and then to the maven ant tasks.  One of these is not passing system properties correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 10:06:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 16 Jun 2009 10:06:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1851) Investigate the
 failure
 org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
Message-ID: <10648726.1245161216783.JavaMail.jira@cloud.prod.atl2.jboss.com>

Investigate the failure org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
-------------------------------------------------------------------------------------

                 Key: EJBTHREE-1851
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1851
             Project: EJB 3.0
          Issue Type: Task
          Components: testsuite
    Affects Versions: 1.1.7
            Reporter: jaikiran pai
            Assignee: jaikiran pai


The org.jboss.ejb3.test.container.unit.ContainerTestCase consistently fails with:

javax.naming.NameNotFoundException: Stateful not bound
	at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
	at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
	at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
	at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
	at sun.rmi.transport.Transport$1.run(Transport.java:153)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
	at java.lang.Thread.run(Thread.java:595)
	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
	at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
	at javax.naming.InitialContext.lookup(InitialContext.java:351)
	at org.jboss.ejb3.test.container.unit.ContainerTestCase.testInvocationStatistics(ContainerTestCase.java:93)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
	at junit.extensions.TestSetup.run(TestSetup.java:27)




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 10:28:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 16 Jun 2009 10:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-532) Ant tasks not
 passing properties correctly to AS dist build
In-Reply-To: <17089570.1245161096601.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29912035.1245162536377.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472334#action_12472334 ] 

Paul Gier commented on JBBUILD-532:
-----------------------------------

Looks like the system properties are being passed from maven to Ant (via the antrun plugin) without a problem.  So the issue is with Ant passing the system properties back to maven through the Ant tasks.

> Ant tasks not passing properties correctly to AS dist build
> -----------------------------------------------------------
>
>                 Key: JBBUILD-532
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-532
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - Maint 2009
>
>
> There is a problem passing properties through the antrun plugin and then to the maven ant tasks.  One of these is not passing system properties correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 10:58:08 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 16 Jun 2009 10:58:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1642) Make the
 java ee example runnable on windows
In-Reply-To: <22235800.1244482856551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23155497.1245164288566.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1642:
----------------------------------------

    Assignee: Andy Taylor  (was: Tim Fox)


> Make the java ee example runnable on windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-1642
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1642
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>         Attachments: build.xml
>
>
> The javaee examples are hard-coded for Linux (run.sh is used to start JBoss AS).
> For windows users, they have to manually edit the build files to sue run.bat instead.
> There is a note in the Beta1 release notes about that.
> The windows/linux difference should be parameterized so that the same build file
> could be used on both OSes.
> The windows file (*.bat) must also be checked to ensure they ends with  \r\n

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 10:58:08 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 16 Jun 2009 10:58:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1642) Make the java
 ee example runnable on windows
In-Reply-To: <22235800.1244482856551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4169371.1245164288267.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated JBMESSAGING-1642:
-------------------------------------

    Attachment: build.xml


build.xml for examples/jms/clustered-standalone to run the example on both
windows and un*x families


> Make the java ee example runnable on windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-1642
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1642
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>         Attachments: build.xml
>
>
> The javaee examples are hard-coded for Linux (run.sh is used to start JBoss AS).
> For windows users, they have to manually edit the build files to sue run.bat instead.
> There is a note in the Beta1 release notes about that.
> The windows/linux difference should be parameterized so that the same build file
> could be used on both OSes.
> The windows file (*.bat) must also be checked to ensure they ends with  \r\n

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 11:10:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 16 Jun 2009 11:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22801019.1245165056845.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472348#action_12472348 ] 

Scott M Stark commented on JBAS-7010:
-------------------------------------

The problem is that the http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-security/5.1.0-SNAPSHOT/ contents are not being updated. When I tried to due a deploy from the eap branch its failing to compile, so the pom is out of date. I'm working on getting the snapshot updated.

> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 11:37:56 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Tue, 16 Jun 2009 11:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7024) results of
 list*Messages methods
 of Queues and Topics have wrong meta type definition
Message-ID: <744707.1245166676454.JavaMail.jira@cloud.prod.atl2.jboss.com>

results of list*Messages methods of Queues and Topics have wrong meta type definition
-------------------------------------------------------------------------------------

                 Key: JBAS-7024
                 URL: https://jira.jboss.org/jira/browse/JBAS-7024
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: JBAPP_5_0 rev90256
            Reporter: Lukas Krejci
            Priority: Critical


The MessageListMapper used to define the meta types on list*Messages() methods for Queues and Topics advertises that the resulting type will be:

CollectionMetaType[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]

however the meta type of the actual meta values obtained using collectionValue.getElements() is advertised as:

MapCompositeValue[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]

This discrepancy is affecting the admin console, Jopr and JON because the meta values values have different type than the advertised meta type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 11:37:56 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 16 Jun 2009 11:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7025) Do not rely on single
 "server/target/etc/deployers/metadata-deployer-jboss-beans.xml" list
Message-ID: <11404436.1245166676620.JavaMail.jira@cloud.prod.atl2.jboss.com>

Do not rely on single "server/target/etc/deployers/metadata-deployer-jboss-beans.xml" list
------------------------------------------------------------------------------------------

                 Key: JBAS-7025
                 URL: https://jira.jboss.org/jira/browse/JBAS-7025
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Deployers
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Scott Marlow
            Assignee: Ales Justin
            Priority: Minor
             Fix For: JBossAS-6.0.0.Alpha1


We should not rely on the single "server/target/etc/deployers/metadata-deployer-jboss-beans.xml" list.  Deployments should be self contained with proper jboss-scanning.xml (or whatever is necessary).  

This comes from development forum email.  Thread starts at http://lists.jboss.org/pipermail/jboss-development/2009-June/014537.html.  Also see http://lists.jboss.org/pipermail/jboss-development/2009-June/014599.html + http://lists.jboss.org/pipermail/jboss-development/2009-June/014603.html


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 11:44:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 16 Jun 2009 11:44:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <52677.1245167097384.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark reassigned JBAS-7010:
-----------------------------------

    Assignee: Paul Gier  (was: Scott M Stark)


I'm seeing the following when trying to deploy an updated snapshot;
[535][valkyrie: security]$ rm -rf /home/svn/repository.jboss.org/maven2/org/jboss/jbossas/jboss-as-system-jmx
[536][valkyrie: security]$ mvn -U package
[INFO] Scanning for projects...
WAGON_VERSION: 1.0-beta-2
[INFO] ------------------------------------------------------------------------
[INFO] Building JBoss Application Server Security
[INFO]    task-segment: [package]
[INFO] ------------------------------------------------------------------------
[INFO] snapshot org.jboss.jbossas:jboss-as-system-jmx:5.1.0-SNAPSHOT: checking for updates from snapshots.jboss.org
Downloading: http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-system-jmx/5.1.0-SNAPSHOT/jboss-as-system-jmx-5.1.0-20090107.041038-32.pom
3K downloaded
[WARNING] POM for 'org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.jboss.jbossas:jboss-as-system-jmx at Artifact [org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile]
[INFO] snapshot org.jboss.jbossas:jboss-as-j2se:5.1.0-SNAPSHOT: checking for updates from snapshots.jboss.org
Downloading: http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-system-jmx/5.1.0-SNAPSHOT/jboss-as-system-jmx-5.1.0-20090107.041038-32.jar
281K downloaded
[INFO] [enforcer:enforce {execution: ban-bad-dependencies}]
[WARNING] POM for 'org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.jboss.jbossas:jboss-as-system-jmx at Artifact [org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile]
[INFO] [enforcer:enforce {execution: enforce-java-maven-versions}]
[WARNING] POM for 'org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.jboss.jbossas:jboss-as-system-jmx at Artifact [org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile]
[INFO] [enforcer:enforce {execution: enforce-plugin-versions}]
[INFO] snapshot org.jboss.jbossas:jboss-as-component-matrix:5.1.0-SNAPSHOT: checking for updates from snapshots.jboss.org
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[WARNING] POM for 'org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.jboss.jbossas:jboss-as-system-jmx at Artifact [org.jboss.jbossas:jboss-as-system-jmx:pom:5.1.0-SNAPSHOT:compile]
[INFO] [compiler:compile]
[INFO] Compiling 67 source files to /Users/svn/JBossAS/branches/JBPAPP_5_0/security/target/classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/jce/JCEProviderServiceMBean.java:[31,7] cannot access org.jboss.system.Service
file org/jboss/system/Service.class not found
public interface JCEProviderServiceMBean extends ServiceMBean

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIContextEstablishment.java:[31,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIContextEstablishment.java:[32,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[34,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[35,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[36,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[37,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[38,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[39,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[40,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[46,46] package org.jboss.managed.api.ManagedOperation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[47,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[48,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[49,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[50,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[51,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[52,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[53,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[54,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityManager.java:[57,7] cannot access org.jboss.kernel.spi.dependency.KernelControllerContextAware
file org/jboss/kernel/spi/dependency/KernelControllerContextAware.class not found
public class JaasSecurityManager extends ServiceMBeanSupport

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBindingBean.java:[27,24] package org.apache.log4j does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBindingBean.java:[36,11] cannot find symbol
symbol  : class Logger
location: class org.jboss.security.integration.JNDIBindingBean

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[26,31] package org.jboss.aop.joinpoint does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[27,31] package org.jboss.aop.joinpoint does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[28,32] package org.jboss.dependency.spi does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[29,39] package org.jboss.kernel.spi.dependency does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordMaskManagement.java:[42,24] package org.apache.log4j does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[61,24] cannot find symbol
symbol  : class Invocation
location: class org.jboss.security.integration.password.PasswordLifecycleCallback

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[94,23] cannot find symbol
symbol  : class ControllerContext
location: class org.jboss.security.integration.password.PasswordLifecycleCallback

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[118,25] cannot find symbol
symbol  : class ControllerContext
location: class org.jboss.security.integration.password.PasswordLifecycleCallback

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordLifecycleCallback.java:[124,43] cannot find symbol
symbol  : class ControllerContext
location: class org.jboss.security.integration.password.PasswordLifecycleCallback

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/password/PasswordMaskManagement.java:[55,11] cannot find symbol
symbol  : class Logger
location: class org.jboss.security.integration.password.PasswordMaskManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[32,48] package org.jboss.aop.microcontainer.aspects.jmx does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[33,46] package org.jboss.managed.api.ManagedOperation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[34,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[35,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[36,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[37,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[38,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/auth/login/XMLLoginConfig.java:[39,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[32,48] package org.jboss.aop.microcontainer.aspects.jmx does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[33,46] package org.jboss.managed.api.ManagedOperation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[34,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[35,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[36,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[37,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[38,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[39,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/SecurityConfig.java:[40,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[27,22] package javax.xml.bind does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[28,22] package javax.xml.bind does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[30,44] package org.jboss.deployers.vfs.spi.deployer does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[31,45] package org.jboss.deployers.vfs.spi.structure does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[32,25] package org.jboss.virtual does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[44,53] cannot find symbol
symbol: class JAXBDeployer
public class JAXBElementParsingDeployer<T,V> extends JAXBDeployer 

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[47,13] cannot find symbol
symbol  : class JAXBContext
location: class org.jboss.security.deployers.JAXBElementParsingDeployer<T,V>

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[88,26] cannot find symbol
symbol  : class VFSDeploymentUnit
location: class org.jboss.security.deployers.JAXBElementParsingDeployer<T,V>

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/JAXBElementParsingDeployer.java:[88,50] cannot find symbol
symbol  : class VirtualFile
location: class org.jboss.security.deployers.JAXBElementParsingDeployer<T,V>

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JBossSecuritySubjectFactory.java:[29,29] package org.jboss.managed.api does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JBossSecuritySubjectFactory.java:[30,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JBossSecuritySubjectFactory.java:[31,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JBossSecuritySubjectFactory.java:[32,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JBossSecuritySubjectFactory.java:[33,40] package org.jboss.managed.api.annotation does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[24,22] package javax.xml.bind does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[25,22] package javax.xml.bind does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[27,31] package org.jboss.deployers.spi does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[28,41] package org.jboss.deployers.structure.spi does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[37,75] cannot find symbol
symbol: class JAXBElement
public class XacmlConfigParsingDeployer extends JAXBElementParsingDeployer<JAXBElement,PDP>

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[41,13] cannot find symbol
symbol  : class JAXBContext
location: class org.jboss.security.deployers.XacmlConfigParsingDeployer

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[74,33] cannot find symbol
symbol  : class DeploymentUnit
location: class org.jboss.security.deployers.XacmlConfigParsingDeployer

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/XacmlConfigParsingDeployer.java:[74,89] cannot find symbol
symbol  : class DeploymentException
location: class org.jboss.security.deployers.XacmlConfigParsingDeployer

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/AclConfigParsingDeployer.java:[24,44] package org.jboss.deployers.vfs.spi.deployer does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/AclConfigParsingDeployer.java:[27,25] package org.jboss.virtual does not exist

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/AclConfigParsingDeployer.java:[35,46] cannot find symbol
symbol: class SchemaResolverDeployer
public class AclConfigParsingDeployer extends SchemaResolverDeployer<ACLConfiguration>

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/deployers/AclConfigParsingDeployer.java:[44,36] cannot find symbol
symbol  : class VirtualFile
location: class org.jboss.security.deployers.AclConfigParsingDeployer

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIContextEstablishment.java:[43,1] cannot find symbol
symbol: class ManagementObject
@ManagementObject(name = "JNDIContextEstablishment", componentType = @ManagementComponent(

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[61,1] cannot find symbol
symbol: class ManagementObject
@ManagementObject(name="JNDIBasedSecurityManagement", componentType = @ManagementComponent(type = "MCBean", subtype = "Security"),

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[107,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[132,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[155,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[177,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[202,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[224,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[231,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[238,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[245,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[252,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[341,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[108,1] cannot find symbol
symbol: class ManagementObject
@ManagementObject(componentType = @ManagementComponent(type = "MCBean", subtype = "Security"), properties = ManagementProperties.EXPLICIT)

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[375,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/integration/JNDIBasedSecurityManagement.java:[400,4] cannot find symbol
symbol  : class ManagementOperation
location: class org.jboss.security.integration.JNDIBasedSecurityManagement

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[194,4] cannot find symbol
symbol  : class ManagementObjectID
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[195,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[206,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[227,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[252,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[263,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[284,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[305,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain

/Users/svn/JBossAS/branches/JBPAPP_5_0/security/src/main/org/jboss/security/plugins/JaasSecurityDomain.java:[329,4] cannot find symbol
symbol  : class ManagementProperty
location: class org.jboss.security.plugins.JaasSecurityDomain


[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9 seconds
[INFO] Finished at: Tue Jun 16 08:43:18 PDT 2009
[INFO] Final Memory: 14M/26M
[INFO] ------------------------------------------------------------------------
[537][valkyrie: security]$ 


> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Paul Gier
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 12:29:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 16 Jun 2009 12:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1857046.1245169796753.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472366#action_12472366 ] 

Paul Gier commented on JBAS-7010:
---------------------------------

I checked out the branch and built the whole thing from the root directory.  It built ok for me, so I'm deploying an update to the snapshot repository now.
Scott, it might have failed for you if you tried building only the security module since the snapshot dependencies that were being retrieved were so old.

Any reason you are not using the default local repo location (.m2/repository) ?  If you have your local repo and the svn checkout in the same place it might cause problems.

> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Paul Gier
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 13:36:56 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Tue, 16 Jun 2009 13:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7024) results of
 list*Messages methods
 of Queues and Topics have wrong meta type definition
In-Reply-To: <744707.1245166676454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15089523.1245173816498.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukas Krejci reassigned JBAS-7024:
----------------------------------

    Assignee: Jason T. Greene


> results of list*Messages methods of Queues and Topics have wrong meta type definition
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-7024
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7024
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBAPP_5_0 rev90256
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>            Priority: Critical
>
> The MessageListMapper used to define the meta types on list*Messages() methods for Queues and Topics advertises that the resulting type will be:
> CollectionMetaType[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> however the meta type of the actual meta values obtained using collectionValue.getElements() is advertised as:
> MapCompositeValue[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> This discrepancy is affecting the admin console, Jopr and JON because the meta values values have different type than the advertised meta type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 13:32:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 16 Jun 2009 13:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7026) EJB3Deployer should
 use post processed metadata instead of merged metadata
Message-ID: <4292241.1245173576566.JavaMail.jira@cloud.prod.atl2.jboss.com>

EJB3Deployer should use post processed metadata instead of merged metadata
--------------------------------------------------------------------------

                 Key: JBAS-7026
                 URL: https://jira.jboss.org/jira/browse/JBAS-7026
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: jaikiran pai
            Assignee: jaikiran pai


The EJB3Deployer currently uses merged metadata:

addInput(MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME);

This should be changed to use post processed metadata.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 13:48:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 16 Jun 2009 13:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-130)
 SOAPSAMLXACMLServlet:: PDP in init method and threadsafe evaluation
Message-ID: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>

SOAPSAMLXACMLServlet:: PDP in init method and threadsafe evaluation
-------------------------------------------------------------------

                 Key: JBID-130
                 URL: https://jira.jboss.org/jira/browse/JBID-130
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 15:34:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 16 Jun 2009 15:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-416)
 AnyURIAttribute->getInstance should trim the string value
Message-ID: <1137530.1245180896442.JavaMail.jira@cloud.prod.atl2.jboss.com>

AnyURIAttribute->getInstance should trim the string value
---------------------------------------------------------

                 Key: SECURITY-416
                 URL: https://jira.jboss.org/jira/browse/SECURITY-416
             Project: JBoss Security and Identity Management
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-sunxacml
    Affects Versions: JBossXACML_2.0.3
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: jbossxacml_2.0.3.SP1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 15:36:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 16 Jun 2009 15:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-416)
 AnyURIAttribute->getInstance should trim the string value
In-Reply-To: <1137530.1245180896442.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13378214.1245181016444.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-416.
----------------------------------

    Resolution: Done


> AnyURIAttribute->getInstance should trim the string value
> ---------------------------------------------------------
>
>                 Key: SECURITY-416
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-416
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-sunxacml
>    Affects Versions: JBossXACML_2.0.3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 15:59:07 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 16 Jun 2009 15:59:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-417) JBossXACML
	2.0.3.SP1
Message-ID: <11421202.1245182347889.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBossXACML 2.0.3.SP1
--------------------

                 Key: SECURITY-417
                 URL: https://jira.jboss.org/jira/browse/SECURITY-417
             Project: JBoss Security and Identity Management
          Issue Type: Release
      Security Level: Public (Everyone can see)
          Components: jboss-sunxacml, JBossXACML
    Affects Versions: JBossXACML_2.0.3
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: jbossxacml_2.0.3.SP1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:08:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 16 Jun 2009 16:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-417) JBossXACML
	2.0.3.SP1
In-Reply-To: <11421202.1245182347889.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21791070.1245182936573.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-417.
----------------------------------

    Resolution: Done


> JBossXACML 2.0.3.SP1
> --------------------
>
>                 Key: SECURITY-417
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-417
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: jboss-sunxacml, JBossXACML
>    Affects Versions: JBossXACML_2.0.3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:10:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 16 Jun 2009 16:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-417) JBossXACML
	2.0.3.SP1
In-Reply-To: <11421202.1245182347889.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32710786.1245183056498.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/SECURITY-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472391#action_12472391 ] 

Anil Saldhana commented on SECURITY-417:
----------------------------------------

 	 Bug  SECURITY-416 	 : AnyURIAttribute->getInstance should trim the string value  	  
   	Release  SECURITY-417:JBossXACML 2.0.3.SP1 	 
   	Bug   SECURITY-414 : XACML: ParsingException should also contain the real cause 

> JBossXACML 2.0.3.SP1
> --------------------
>
>                 Key: SECURITY-417
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-417
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: jboss-sunxacml, JBossXACML
>    Affects Versions: JBossXACML_2.0.3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:16:00 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Tue, 16 Jun 2009 16:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-735) Fix the
 2.0.x-compliance-tests.xml script
In-Reply-To: <8383897.1244526356637.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33514506.1245183360355.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAOP-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone closed JBAOP-735.
--------------------------------



> Fix the 2.0.x-compliance-tests.xml script
> -----------------------------------------
>
>                 Key: JBAOP-735
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-735
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>             Fix For: 2.1.2.GA
>
>
> Currently, if you try to run the precompiled-tests_2.0.x target, this is what you get:
> _run-precompiled-test_2.0.x:
>      [echo] Compiling bridgemethod with optimized=true and instrumentor ${instrumentor}
>      [aopc] Exception in thread "main" java.lang.RuntimeException: Invalid instrumentor ${instrumentor} was used
>      [aopc] 	at org.jboss.aop.instrument.InstrumentorFactory.initialise(InstrumentorFactory.java:75)
>      [aopc] 	at org.jboss.aop.AspectManager$1.run(AspectManager.java:317)
>      [aopc] 	at org.jboss.aop.AspectManager$1.run(AspectManager.java:263)
>      [aopc] 	at java.security.AccessController.doPrivileged(Native Method)
>      [aopc] 	at org.jboss.aop.AspectManager.initManager(AspectManager.java:262)
>      [aopc] 	at org.jboss.aop.AspectManager.instance(AspectManager.java:241)
>      [aopc] 	at org.jboss.aop.AspectManager.instance(AspectManager.java:230)
>      [aopc] 	at org.jboss.aop.standalone.Compiler.compile(Compiler.java:195)
>      [aopc] 	at org.jboss.aop.standalone.Compiler.main(Compiler.java:88)
> BUILD FAILED
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/build-tests-jdk50.xml:275: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:256: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:486: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:287: The following error occurred while executing this line:
> /qa/hudson_ws/workspace/jboss-aop-head-testsuite/trunk/aop/2.0.x-compliance-tests.xml:654: Java returned: 1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:16:00 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 16 Jun 2009 16:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7025) Do not rely on
 single
 "server/target/etc/deployers/metadata-deployer-jboss-beans.xml" list
In-Reply-To: <11404436.1245166676620.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24414483.1245183360911.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow reassigned JBAS-7025:
----------------------------------

    Assignee: Scott Marlow  (was: Ales Justin)


> Do not rely on single "server/target/etc/deployers/metadata-deployer-jboss-beans.xml" list
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7025
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7025
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>            Priority: Minor
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> We should not rely on the single "server/target/etc/deployers/metadata-deployer-jboss-beans.xml" list.  Deployments should be self contained with proper jboss-scanning.xml (or whatever is necessary).  
> This comes from development forum email.  Thread starts at http://lists.jboss.org/pipermail/jboss-development/2009-June/014537.html.  Also see http://lists.jboss.org/pipermail/jboss-development/2009-June/014599.html + http://lists.jboss.org/pipermail/jboss-development/2009-June/014603.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:21:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 16 Jun 2009 16:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2423) CMS search
 cannot handle empty search string
Message-ID: <32370284.1245183716450.JavaMail.jira@cloud.prod.atl2.jboss.com>

CMS search cannot handle empty search string
--------------------------------------------

                 Key: JBPORTAL-2423
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2423
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal CMS
    Affects Versions: 2.7.2 Final
            Reporter: Chris Laprun
            Assignee: Sohil Shah
             Fix For: 2.7.3 Final


Trying to search CMS for an empty String results in an exception...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:23:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 16 Jun 2009 16:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-130) SOAPSAMLXACMLServlet::
 PDP in init method and threadsafe evaluation
In-Reply-To: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12259656.1245183836752.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-130.
------------------------------

    Resolution: Done


> SOAPSAMLXACMLServlet:: PDP in init method and threadsafe evaluation
> -------------------------------------------------------------------
>
>                 Key: JBID-130
>                 URL: https://jira.jboss.org/jira/browse/JBID-130
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:38:56 2009
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Tue, 16 Jun 2009 16:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
Message-ID: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>

IllegalStateException upon cluster fail-over
--------------------------------------------

                 Key: JBMESSAGING-1657
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.0.SP3.CP05
            Reporter: Justin Bertram
            Assignee: Tim Fox


I set up two cluster nodes like so:

1) unzipped fresh JBoss EAP 4.3 CP04
2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
8) copied <JBOSS_HOME> to <JBOSS_HOME2>
9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"

Then I ran the test (which is attached as JmsTest.java)
 -Start test client connecting to 127.0.0.1
 -Observe client log filling up with "."
 -Drop JBoss running on 127.0.0.1
 -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
 -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:42:56 2009
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Tue, 16 Jun 2009 16:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11599990.1245184976893.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Justin Bertram updated JBMESSAGING-1657:
----------------------------------------

    Attachment: JmsTest.java
                127.0.0.1.log
                127.0.0.2.log


> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05
>            Reporter: Justin Bertram
>            Assignee: Tim Fox
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:42:57 2009
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Tue, 16 Jun 2009 16:42:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18296470.1245184977419.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Justin Bertram updated JBMESSAGING-1657:
----------------------------------------

    Description: 
I set up two cluster nodes like so:

1) unzipped fresh JBoss EAP 4.3 CP04
2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
8) copied <JBOSS_HOME> to <JBOSS_HOME2>
9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"

Then I ran the test (which is attached as JmsTest.java)
 -Start test client connecting to 127.0.0.1
 -Observe client log filling up with "."
 -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
 -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
 -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

  was:
I set up two cluster nodes like so:

1) unzipped fresh JBoss EAP 4.3 CP04
2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
8) copied <JBOSS_HOME> to <JBOSS_HOME2>
9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"

Then I ran the test (which is attached as JmsTest.java)
 -Start test client connecting to 127.0.0.1
 -Observe client log filling up with "."
 -Drop JBoss running on 127.0.0.1
 -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
 -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)



> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05
>            Reporter: Justin Bertram
>            Assignee: Tim Fox
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:42:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 16 Jun 2009 16:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7010)
 JndiLoginInitialContextFactory
 is not creating expected SecurityContext
In-Reply-To: <2519246.1244676656466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30767693.1245184976717.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-7010.
---------------------------------

    Resolution: Done
      Assignee: Scott M Stark  (was: Paul Gier)


With Paul's refresh of the snapshots the ejb client is running without the authentication failure:

[506][valkyrie: jbas5-ejb-client]$ java -jar target/jbas5-ejb-client-1.0.jar 
Creating JNDI InitialContext with env [{java.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory, java.naming.provider.url=jnp://127.0.0.1:1099/, java.naming.security.principal=javaduke, java.naming.security.credentials=anotherduke}]...
Created JNDI InitialContext [javax.naming.InitialContext at be0e27].
Looking up name 'SecureProfileService/remote' from InitialContext...
Found Object: Proxy to jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3 implementing [interface org.jboss.profileservice.spi.ProfileService]
Looking up name 'SecureManagementView/remote' from InitialContext...
Found Object: Proxy to jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3 implementing [interface org.jboss.deployers.spi.management.ManagementView]
Looking up name 'SecureDeploymentManager/remote' from InitialContext...
Found Object: Proxy to jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3 implementing [interface org.jboss.deployers.spi.management.deploy.DeploymentManager]
[507][valkyrie: jbas5-ejb-client]$ 

> JndiLoginInitialContextFactory is not creating expected SecurityContext
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7010
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7010
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Related to JBAS-6982, a SecurityContext is not resulting from the JndiLoginInitialContextFactory operation. The result is that a SecurityContext with a null principal and credential ends up being created by the org.jboss.ejb3.security.client.SecurityClientInterceptor even though there is a non-null principal and credential available.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:42:57 2009
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Tue, 16 Jun 2009 16:42:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18066360.1245184977186.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Justin Bertram updated JBMESSAGING-1657:
----------------------------------------

    Attachment: client.log


> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05
>            Reporter: Justin Bertram
>            Assignee: Tim Fox
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 16:51:20 2009
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Tue, 16 Jun 2009 16:51:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26928617.1245185480226.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Justin Bertram reassigned JBMESSAGING-1657:
-------------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


I'm assigning this to Howard as he is the 1.4.x maintainer.

> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 17:24:12 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 16 Jun 2009 17:24:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-532) Ant tasks not
 passing properties correctly to AS dist build
In-Reply-To: <17089570.1245161096601.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32586366.1245187452157.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472405#action_12472405 ] 

Paul Gier commented on JBBUILD-532:
-----------------------------------

Created http://jira.codehaus.org/browse/MANTTASKS-153.

> Ant tasks not passing properties correctly to AS dist build
> -----------------------------------------------------------
>
>                 Key: JBBUILD-532
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-532
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - Maint 2009
>
>
> There is a problem passing properties through the antrun plugin and then to the maven ant tasks.  One of these is not passing system properties correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 18:01:11 2009
From: jira-events at lists.jboss.org (Richard Taylor (JIRA))
Date: Tue, 16 Jun 2009 18:01:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6314) Problems using EJB
 + Quartz + Seam
In-Reply-To: <29883538.1229034156614.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23960201.1245189671661.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472407#action_12472407 ] 

Richard Taylor commented on JBAS-6314:
--------------------------------------

A potential workaround for this is to disable EAR classloading isolation (in ear-deployer-jboss-beans.xml).  It solved a very similar problem (non Seam) for us in JBoss 5.1.0.  Obviously this isn't an option for everyone.

> Problems using EJB + Quartz + Seam
> ----------------------------------
>
>                 Key: JBAS-6314
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6314
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows Vista
>            Reporter: Diego Coronel
>            Assignee: Andrew Lee Rubinger
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
>  problems using quartz/seam with AS5, it works fine in jboss 4.2.2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 19:50:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Tue, 16 Jun 2009 19:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREFLECT-3) Use an
 appropriate Javassist ClassPool
In-Reply-To: <12331947.1165415635891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30504405.1245196256816.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBREFLECT-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472412#action_12472412 ] 

Flavia Rainone commented on JBREFLECT-3:
----------------------------------------

Currently, I'm taking a very good look at all ClassPool implementations, from jassist.ClassPool to the aop-asintegration class pools. I think that after this is done, I'll have a better understanding of what does what and what belongs where. I'll post my thoughts & questions at the forum once I'm done with this research.

> Use an appropriate Javassist ClassPool
> --------------------------------------
>
>                 Key: JBREFLECT-3
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-3
>             Project: JBoss Reflection
>          Issue Type: Task
>          Components: Javassist
>            Reporter: Adrian Brock
>            Assignee: Flavia Rainone
>
> The javassist reflection utilities use the original shared classpool.
> This does not understand classloaders.
> This should be updated to use a more appropriate ClassPool.
> Good starting points are the  ScopedClassPool from Javassist and the ClassPools from JBossAOP (check AOPClassPool and ClassPool implementations at jboss-aop-asintegration-* subprojects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 20:03:05 2009
From: jira-events at lists.jboss.org (Alex Skor (JIRA))
Date: Tue, 16 Jun 2009 20:03:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6973) Starting JBoss AS
 5.1.0 fails on opensolaris, jdk 1.6.0_13
In-Reply-To: <18440810.1243287236718.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16248773.1245196985744.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472413#action_12472413 ] 

Alex Skor commented on JBAS-6973:
---------------------------------

I see the same error on Sun OS (not opensolaris) with Sun JDK 1.5.0_18 and Jboss 5.1.0GA:
$uname -a
SunOS mars5 5.10 Generic_127127-11 sun4u sparc SUNW,SPARC-Enterprise


> Starting JBoss AS 5.1.0 fails on opensolaris, jdk 1.6.0_13
> ----------------------------------------------------------
>
>                 Key: JBAS-6973
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6973
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: System service
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: OpenSolaris build 111, running Sun Java 1.6.0_13
>            Reporter: Vincent De Baere
>            Assignee: Dimitris Andreadis
>            Priority: Minor
>         Attachments: as-5.1.0.GA-profile.xml.patch
>
>
> Starting up JBoss AS 5.1.0.GA fails with the following message:
> 23:31:11,553 INFO  [JMXKernel] Legacy JMX core initialized
> 23:31:16,747 ERROR [AbstractKernelController] Error installing to Instantiated: name=AttachmentStore state=Described
> java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[java.net.URI] actual=[java.io.File]
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:395)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:153)
> 	at org.jboss.reflect.plugins.introspection.ReflectConstructorInfoImpl.newInstance(ReflectConstructorInfoImpl.java:106)
> 	at org.jboss.joinpoint.plugins.BasicConstructorJoinPoint.dispatch(BasicConstructorJoinPoint.java:80)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.createTarget(AOPConstructorJoinpoint.java:282)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:103)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:66)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:319)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:297)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130)
> 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76)
> 	at org.jboss.bootstrap.microcontainer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:91)
> 	at org.jboss.bootstrap.microcontainer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:161)
> 	at org.jboss.bootstrap.microcontainer.ServerImpl.doStart(ServerImpl.java:138)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:450)
> 	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)
> Failed to boot JBoss:
> java.lang.IllegalStateException: Incompletely deployed:
> DEPLOYMENTS IN ERROR:
>   Deployment "AttachmentStore" is in error due to: java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[java.net.URI] actual=[java.io.File]
> DEPLOYMENTS MISSING DEPENDENCIES:
>   Deployment "ProfileService" is missing the following dependencies:
>     Dependency "jboss.kernel:service=KernelController" (should be in state "Installed", but is actually in state "**ERROR**")
>     Dependency "ProfileServiceDeployer" (should be in state "Installed", but is actually in state "Instantiated")
>   Deployment "ProfileServiceDeployer" is missing the following dependencies:
>     Dependency "AttachmentStore" (should be in state "Installed", but is actually in state "**ERROR**")
>   Deployment "ProfileServiceBootstrap" is missing the following dependencies:
>     Dependency "jboss.kernel:service=Kernel" (should be in state "Installed", but is actually in state "**ERROR**")
>     Dependency "ProfileService" (should be in state "Installed", but is actually in state "Instantiated")
>   Deployment "ProfileServicePersistenceDeployer" is missing the following dependencies:
>     Dependency "AttachmentStore" (should be in state "Installed", but is actually in state "**ERROR**")
> 	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.microcontainer.ServerImpl.doStart(ServerImpl.java:142)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:450)
> 	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)
> 23:31:18,389 INFO  [ServerImpl] Runtime shutdown hook called, forceHalt: true
> 23:31:18,402 INFO  [ServerImpl] Shutdown complete
> Shutdown complete
> Halting VM

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 20:03:05 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Tue, 16 Jun 2009 20:03:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
Message-ID: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>

Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
------------------------------------------------------------------------------------------

                 Key: JBMETA-208
                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.0.1.GA
         Environment: JBoss AS 5.1.0.GA
            Reporter: Richard Kennard
            Assignee: Alexey Loubyansky


The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...

<ejb-jar>
</ejb-jar>

...instead of...

<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">
</ejb-jar>

...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.

An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...

http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html

...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 20:46:57 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Tue, 16 Jun 2009 20:46:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4032450.1245199617494.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472418#action_12472418 ] 

Flavia Rainone commented on JBAS-6888:
--------------------------------------

I've tested Kabir suggestion and it works. Following Kabir's instructions, I'm creating a JBAOP associated with this Jira for the implementation of Kabir's fix.

> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Flavia Rainone
>         Attachments: server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 16 20:49:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Tue, 16 Jun 2009 20:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-736) Create workaround
 for IBM JVM's Clas.getDeclaringClass bug
Message-ID: <33122186.1245199796446.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create workaround for IBM JVM's Clas.getDeclaringClass bug
----------------------------------------------------------

                 Key: JBAOP-736
                 URL: https://jira.jboss.org/jira/browse/JBAOP-736
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.1.GA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: 2.1.2.GA


The IBM's JVM returns null when the generated advisor's constructor invokes this.getClass().getDeclaringClass(), thus causing JBoss AOP from version 2.0 on to not work with IBM's JVM.

The call to getDeclaringClass() needs to be replaced.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 00:28:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 17 Jun 2009 00:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1644) Work out a
 suitable way to provide JBM examples/doc for AS 5
In-Reply-To: <25933843.1244563136418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33358238.1245212936459.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472427#action_12472427 ] 

Howard Gao commented on JBMESSAGING-1644:
-----------------------------------------

After discussion, we decide for the moment just put the examples to the JBoss Messaging download page and add a link to the upcoming AS5 release notes.



> Work out a suitable way to provide JBM examples/doc for AS 5
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1644
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1644
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.5.GA
>
>
> Current AS 5 distribution kit doesn't have JBM doc/examples of the corresponding version included, that makes it very inconvenient to use JBM with AS5. Users often get confused with which version of JBM is the correct version, and where to get the resouces (docs, examples).
> We have to provide a solution to that. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 02:05:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 17 Jun 2009 02:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2848448.1245218756832.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472434#action_12472434 ] 

jaikiran pai commented on JBMETA-208:
-------------------------------------

Alexey,

I am not yet sure whether this is some issue with JBMETA or EJBTHREE (which probably picks up the deployment incorrectly starts spitting out the WARN messages). If it turns out to be an EJB3 issue please assign this to me.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 03:04:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 17 Jun 2009 03:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6777) 'interleaving' prop
 on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24333999.1245222296739.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-6777.
---------------------------------

    Resolution: Done


The reflection info was marking the interleaving property as not readable, I guess because there is an issue isX and reflection naming rules.


> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 03:22:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 17 Jun 2009 03:22:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7026) EJB3Deployer should
 use post processed metadata instead of merged metadata
In-Reply-To: <4292241.1245173576566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2088486.1245223377345.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-7026.
--------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


> EJB3Deployer should use post processed metadata instead of merged metadata
> --------------------------------------------------------------------------
>
>                 Key: JBAS-7026
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7026
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The EJB3Deployer currently uses merged metadata:
> addInput(MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME);
> This should be changed to use post processed metadata.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 03:23:59 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 17 Jun 2009 03:23:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-549) ConnectionTable:
 spurious Connection instances on concurrent connects
In-Reply-To: <10580511.1183710592881.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29148932.1245223439404.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic updated JGRP-549:
-------------------------------------

    Fix Version/s: 2.4.7
                       (was: 2.6)


Backported to 2.4 Branch. Affected files are ConnectionTable.java and BasicConnectionTable.java

> ConnectionTable: spurious Connection instances on concurrent connects
> ---------------------------------------------------------------------
>
>                 Key: JGRP-549
>                 URL: https://jira.jboss.org/jira/browse/JGRP-549
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.4.7
>
>
> If we have members A and B, and they don't yet have connections to each other, and start sending messages to each other at the exact same time, then we run into the following scenario:
> - A attempts to connect to B (new Socket())
> - B attempts to connect to A
> - A accepts B's connection and adds an entry for B into its table
> - B adds an entry for A into its table
> - B gets the accept() from A, but doesn't add the new Connection into its table because there is already a Connection. This leads to a spurious Connection object, which will only be closed and garbage collected once A or B leaves the cluster
> - We used to close Connections which were already in the table, but this lead to ping-pong effects where concurrent initial senders always closed each others connections
> - Even worse: a new Socket() always creates a new Connection object and places it into the table, *regardless* of whether a Connection for a given destination already exists or not !
> GOAL:
> #1 Have only 1 TCP connection between any 2 members
> #2 Establish a handshaking mechanism, to avoid spurious connections
> SOLUTION:
> - When A establishes a connection to B, A needs to get agreement from B first (and vice versa)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 03:25:56 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 17 Jun 2009 03:25:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-549) ConnectionTable:
 spurious Connection instances on concurrent connects
In-Reply-To: <10580511.1183710592881.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9643009.1245223556434.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic updated JGRP-549:
-------------------------------------

    Fix Version/s: 2.6


> ConnectionTable: spurious Connection instances on concurrent connects
> ---------------------------------------------------------------------
>
>                 Key: JGRP-549
>                 URL: https://jira.jboss.org/jira/browse/JGRP-549
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6
>
>
> If we have members A and B, and they don't yet have connections to each other, and start sending messages to each other at the exact same time, then we run into the following scenario:
> - A attempts to connect to B (new Socket())
> - B attempts to connect to A
> - A accepts B's connection and adds an entry for B into its table
> - B adds an entry for A into its table
> - B gets the accept() from A, but doesn't add the new Connection into its table because there is already a Connection. This leads to a spurious Connection object, which will only be closed and garbage collected once A or B leaves the cluster
> - We used to close Connections which were already in the table, but this lead to ping-pong effects where concurrent initial senders always closed each others connections
> - Even worse: a new Socket() always creates a new Connection object and places it into the table, *regardless* of whether a Connection for a given destination already exists or not !
> GOAL:
> #1 Have only 1 TCP connection between any 2 members
> #2 Establish a handshaking mechanism, to avoid spurious connections
> SOLUTION:
> - When A establishes a connection to B, A needs to get agreement from B first (and vice versa)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 03:37:56 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 17 Jun 2009 03:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Admin Join problem
 -GMS flush by coordinator failed
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31724581.1245224276777.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472445#action_12472445 ] 

Vladimir Blagojevic commented on JGRP-985:
------------------------------------------

Ronn, I am not sure if this is fixed on 2.6 branch. This test scenario is also a bit unusual and hard to reproduce - having three nodes fail at the same time. I wonder if there is a way to trigger a scenario. I believe when you say that this lookup happens and I think the reason is that the view in coordinator gets corrupted somehow so that flush can never succeed and thus no new member can ever join. 

> Admin  Join problem -GMS flush by coordinator failed
> ----------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 04:56:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 17 Jun 2009 04:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6784) Add support for JMS
 ServerPeer
 managed object to support enabling metric collection through the console
In-Reply-To: <4119905.1239740302404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2337058.1245229016949.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-6784.
---------------------------------

    Resolution: Done


There is a "jboss.messaging:service=ServerPeer" component of type ComponentType("JMS", "ServerPeer")

   public void testServerPeer() throws Exception
   {
      ManagementView mgtView = getManagementView();
      ComponentType type = new ComponentType("JMS", "ServerPeer");
      ManagedComponent component = mgtView.getComponent("jboss.messaging:service=ServerPeer", type);
      assertNotNull(component);
      
      log.info("Properties: "+component.getProperties().keySet());
      
      ManagedOperation o = getOperation(component, "listMessageCountersAsHTML", new String[0]);
      MetaValue v = o.invoke(new MetaValue[0]);
      assertNotNull("null operation return value", v);
      log.debug("result" + v);
   }

> Add support for JMS ServerPeer managed object to support enabling metric collection through the console
> -------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6784
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6784
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Charles Crouch
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> See 
> https://jira.jboss.org/jira/browse/JBAS-6720?focusedCommentId=12461916#action_12461916
> https://jira.jboss.org/jira/browse/JBAS-6720?focusedCommentId=12461917#action_12461917
> for more info on why this would be a good thing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 05:05:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 17 Jun 2009 05:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6720) Make sure that the
 metrics for
 Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as
 ViewUse.STATISTIC
In-Reply-To: <7508166.1238615242987.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20835543.1245229556966.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-6720.
---------------------------------

    Resolution: Done


The ServerPeer managed object (name="jboss.messaging:service=ServerPeer", type=ComponentType("JMS", "ServerPeer")) exposes the enableMessageCounters property.

1182 [main] INFO org.jboss.test.profileservice.test.JmsDestinationUnitTestCase  - Properties: [defaultTopicJNDIContext, enableMessageCounters, providerVersion, postOffice, defaultExpiryQueue, suckerPassword, supportsFailover, JMSProviderName, clientAopConfig, serverAopConfig, JMSVersion, strictTck, providerMinorVersion, clusterPullConnectionFactoryName, defaultRedeliveryDelay, messageCounterSamplePeriod, defaultMessageCounterHistoryDayLimit, persistenceManager, messageStatistics, failoverCompleteTimeout, jmsUserManager, defaultQueueJNDIContext, messageCounters, serverPeerID, providerMajorVersion, version, failoverStartTimeout, useXAForMessagePull, JMSMajorVersion, recoverDeliveriesTimeout, JMSUserManager, defaultMaxDeliveryAttempts, JMSMinorVersion, defaultDLQ, securityDomain, defaultPreserveOrdering]


> Make sure that the metrics for Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as ViewUse.STATISTIC
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6720
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6720
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: JBoss AS Branch_5_x r86586, embjopr r266
> EmbJopr TS: testQueueMetrics
>            Reporter: Farah Juma
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Steps to reproduce:
> Create a new Topic or Queue using Embedded Jopr. Send some messages to the Topic or Queue. Navigate to the "Metrics" tab for the resource. The metrics do not get updated to reflect this change. All the values are 0.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 06:33:56 2009
From: jira-events at lists.jboss.org (Pavel Slavicek (JIRA))
Date: Wed, 17 Jun 2009 06:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7029) Test
 org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean
 fails on JDK6
Message-ID: <9161934.1245234836800.JavaMail.jira@cloud.prod.atl2.jboss.com>

Test org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean fails on JDK6
----------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7029
                 URL: https://jira.jboss.org/jira/browse/JBAS-7029
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: JBossAS-5.1.0.GA
         Environment: Windows and Linux 
JDK6
            Reporter: Pavel Slavicek
            Assignee: Shelly McGowan


Test org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean fails on JDK6 on line 

      Set<ManagedOperation> ops = mo.getOperations();
      log.debug(ops);
      assertEquals("Ops count is 8", 8, ops.size());

JDK6 contains JMX 1.4 and ThreadMXBean has 11 operations.

Test log:
junit.framework.AssertionFailedError: Ops count is 8 expected:&lt;8&gt; but was:&lt;11&gt;


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 06:41:56 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Wed, 17 Jun 2009 06:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7024) results of
 list*Messages methods
 of Queues and Topics have wrong meta type definition
In-Reply-To: <744707.1245166676454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24957738.1245235316590.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukas Krejci updated JBAS-7024:
-------------------------------

    Attachment: JBAS-7024.patch


I'm attaching a simple patch that fixed the issue for me.

> results of list*Messages methods of Queues and Topics have wrong meta type definition
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-7024
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7024
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBAPP_5_0 rev90256
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>            Priority: Critical
>         Attachments: JBAS-7024.patch
>
>
> The MessageListMapper used to define the meta types on list*Messages() methods for Queues and Topics advertises that the resulting type will be:
> CollectionMetaType[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> however the meta type of the actual meta values obtained using collectionValue.getElements() is advertised as:
> MapCompositeValue[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> This discrepancy is affecting the admin console, Jopr and JON because the meta values values have different type than the advertised meta type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 06:41:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 17 Jun 2009 06:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26456428.1245235316860.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472470#action_12472470 ] 

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

Bela

Here are my thoughts on this issue:

The problem
-----------
A user starts up jgroups, possibly specifying values for the some of the IP addresses which JGroups makes use of: 

* UDP: bind_addr, mcast_addr, diagnostics_addr 
* TCP: bind_addr, initial_hosts 

The user can specify zero or more such values, relying on defaults if values are left unspecified.

Possible Requirements
------------
1. We want to make sure that the complete set of values is specified, before any sockets are created. 
2. We assume that a mixed configuration of IPv4 and IPv6 addresses in one stack is unwanted. 
3. The decision to use a set of addresses must agree with the stacks available (or preferred in the case of dual stack availability) on the host.

Design for a solution (for UDP/TCP layers)
---------------------

Idea:
A. define defaults for all required IP address values above for both IPv4 and IPv6
B. at stack initialization, collect up all the values specified by the user (after parameters processing in UDP/TCP)
C. - if one or more values specified:
D.   - check if a consistent set of either IPv4 or IPv6 addresses
E.     - if not consistent set, raise exception and don't start stack
F.     - if consistent set, set useIPv4/useIPv6 variable to record the consistency, and complete the set with appropriate defaults

// NOTE: this takes the user's decision on IPv4 vs IPv6 and goes with it, making no checks to see if the 
// chosen stack is available on the machine. The user may receive Socket exceptions is the stack
// is not available, or if the stack preference (java.net.preferIPv4Stack) is set differently from the users choice
// on a dual stack machine. 
 
G. - if zero values specified: 
H.   - check to see which stacks are available on the machine (by enumerating all network interfaces and
     for each, checking if IPv4 or IPv6 addresses are defined) and set the values isIPv4Available/isIPv6Available
I.     - if only IPv4 is available, set useIPv4=true and complete the set of approproate defaults
J.     - if only IPv6 is available, set useIPv6=true and complete set of appropriate defaults
K.     - if both IPv6 and IPv4 are available, use JVM property java.net.preferIPv4Stack value to decide which stack to use
       and complete the set of appropriate defaults

// NOTE: this checks the presence of the IPv4 and IPv6 stacks, and chooses one, taking into account the JVM stack preference 
// setting. This determines uniquely whether IPv4 or IPv6 sockets will be created by the JVM. This may result in IPv4 addresses being
// used with IPv6 sockets (and so IPv4-mapped addresses used internally).

L. before sockets are created, we end up with the following values set:
     useIPv4/useIPv6, which indicates which IP stack was chosen, based on user specifying values (or not)
     isIPv4Available/isIPv6Available which indicates which stacks are available
     a complete consistent set of values for the IP addresses that JGroups needs

This design does not meet requirement 3 if the user specifies one or more values. That is, he could specify IPv6 addresses
when in fact the JVM has only an IPv4 stack available, or has a preference for an IPv4 stack. That could be changed by 
additionally checking if the consistent set of values specified by the user also is supported with a stack on the host (as is done in the case
where no values are specified). Don't know how involved you want JGroups to be in checking IP address configuratioin. This could be achieved for little extra cost
by checking stack availability before hand.    

With respect to probe.sh/Probe.java, I believe we need to also check what kind of stacks we have available in order to 
be able to multicast, without handling exceptions for stacks not being available. This would keep all the IP version
stuff separate from the general code. 

For the case of TCPPING and making defaults for initial_hosts consistent, could this be done within TCPPING when it 
received the LOCAL_ADDR and check consistency between LOCAL_ADDR and its initial hosts parameters? If the address
passed in by LOCAL_ADDR and the specified values for initial_hosts don't agree, then raise an exception and don't start the stack.
 
 


> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 06:50:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 17 Jun 2009 06:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16795634.1245235856544.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472474#action_12472474 ] 

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

Could add static functions to check stack availability to Util:

Util.isIPv4Available()
Util.isIPv6Available()



> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 07:12:56 2009
From: jira-events at lists.jboss.org (Stefan Anzinger (JIRA))
Date: Wed, 17 Jun 2009 07:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-993)
 InstanceNotFoundException when
 destroying jchannel (TP.ProtocolAdapter not found in MBean server)
Message-ID: <13853647.1245237176489.JavaMail.jira@cloud.prod.atl2.jboss.com>

InstanceNotFoundException when destroying jchannel (TP.ProtocolAdapter not found in MBean server)
-------------------------------------------------------------------------------------------------

                 Key: JGRP-993
                 URL: https://jira.jboss.org/jira/browse/JGRP-993
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.6.9
         Environment: Windows
            Reporter: Stefan Anzinger
            Assignee: Bela Ban
            Priority: Minor


When using shared transport with org.jgroups.jmx.JChannel there occurs a javax.management.InstanceNotFoundException when destroying the cannel.
It has no major impact as the exception is caught and not thrown outside of jgroups. Unfortunately the exception is logged as error where obviously is no error.

See the testcase and exception:

import java.io.ByteArrayInputStream;
import org.w3c.dom.*;
import javax.management.MBeanServer;
import javax.management.MBeanServerFactory;
import javax.xml.parsers.*;
import junit.framework.TestCase;


public class TestJGroups extends TestCase {
    /**
     * Tests the receiveLocalMessages feature on multiplex
     * channels.
     * 
     * <h2>Course of action</h2>
     * <ol>
     *   <li>Creates tow physical channels</li>
     *   <li>For each physical channel a mux channel is created</li>
     *   <li>Receive Local messages is turned off on the mux channels</li>
     *   <li>Local address has to be set manually after connecting the physical channels (This may be done automatically)</li>
     *   <li>Message is sent from the first mux to the second mux channel</li>
     * </ol>
     * 
     * @throws Exception
     */
    public void testSharedTransport() throws Exception
    {
        MBeanServer mbeanserver = MBeanServerFactory.createMBeanServer("testserver");
        org.jgroups.jmx.JChannel channel1 = new org.jgroups.jmx.JChannel();
        channel1.setClusterConfig(getConfig("singletonA"));
        channel1.setObjectName("test:service=Channel");
        channel1.create();
        channel1.setClusterName("Cluster1");
        channel1.start();
        channel1.stop();
        channel1.destroy();
        MBeanServerFactory.releaseMBeanServer(mbeanserver);
    }
    
    
    private Element getConfig(String singletonName) throws Exception {
        String config = 
            "<config>                                                                           " +
            "  <UDP mcast_recv_buf_size=\"80000\" mcast_send_buf_size=\"150000\"                " +
            "      mcast_port=\"32233\" mcast_addr=\"228.0.0.1\"                                " +
            "      ip_ttl=\"32\" singleton_name=\"" + singletonName + "\"/>                     " +
            "  <PING/>                                                                          " +
            "  <FD_SOCK/>                                                                       " +
            "  <VERIFY_SUSPECT timeout=\"15000\"/>                                              " +
            "  <pbcast.NAKACK gc_lag=\"50\" retransmit_timeout=\"300,600,1200,2400,48000\"/>    " +
            "  <UNICAST timeout=\"600,1200,2000,25000\"/>                                       " +
            "  <FRAG frag_size=\"8096\"/>                                                       " +
            "  <pbcast.STABLE desired_avg_gossip=\"20000\" max_bytes=\"500000\"/>               " +
            "  <pbcast.GMS print_local_addr=\"true\" join_timeout=\"60000\" shun=\"true\" />    " +
            "</config>                                                                          ";
        DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
        DocumentBuilder db = dbf.newDocumentBuilder();
        Document d = db.parse(new ByteArrayInputStream(config.getBytes()));
        return d.getDocumentElement();
    }

}


2009-06-17 13:05:49,409 [main] ERROR - org.jgroups.jmx.JmxConfigurator - failed to unregister test:service=Channel,protocol=TP.ProtocolAdapter
javax.management.InstanceNotFoundException: test:service=Channel,protocol=TP.ProtocolAdapter
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1010)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:354)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:527)
	at org.jgroups.jmx.JmxConfigurator.unregisterProtocols(JmxConfigurator.java:121)
	at org.jgroups.jmx.JChannel.destroy(JChannel.java:256)
	at com.j2fe.clustering.impl.TestJGroups.testSharedTransport(TestJGroups.java:41)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 07:16:56 2009
From: jira-events at lists.jboss.org (Stefan Anzinger (JIRA))
Date: Wed, 17 Jun 2009 07:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-993)
 InstanceNotFoundException when
 destroying jchannel (TP.ProtocolAdapter not found in MBean server)
In-Reply-To: <13853647.1245237176489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24226415.1245237416517.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472477#action_12472477 ] 

Stefan Anzinger commented on JGRP-993:
--------------------------------------

I have pasted an invalid javadoc comment on this issue, here is the right one :-): 

    /**
     * Tests the shared transport inclusive the registering MBeans
     * channels.
     * 
     * <h2>Course of action</h2>
     * <ol>
     *   <li>Start MBean Server</li>
     *   <li>Create MBean JChannel (Registers protocols in MBean Server</li>
     *   <li>Start JChannel</li>
     *   <li>Stop JChannel</li>
     *   <li>Destroy JChannel (Removes all protocols from MBean Server, which gives exception that MBean for TP.ProtocolAdapter does not exist)</li>
     * </ol>
     * 
     * @throws Exception
     */

> InstanceNotFoundException when destroying jchannel (TP.ProtocolAdapter not found in MBean server)
> -------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-993
>                 URL: https://jira.jboss.org/jira/browse/JGRP-993
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.9
>         Environment: Windows
>            Reporter: Stefan Anzinger
>            Assignee: Bela Ban
>            Priority: Minor
>
> When using shared transport with org.jgroups.jmx.JChannel there occurs a javax.management.InstanceNotFoundException when destroying the cannel.
> It has no major impact as the exception is caught and not thrown outside of jgroups. Unfortunately the exception is logged as error where obviously is no error.
> See the testcase and exception:
> import java.io.ByteArrayInputStream;
> import org.w3c.dom.*;
> import javax.management.MBeanServer;
> import javax.management.MBeanServerFactory;
> import javax.xml.parsers.*;
> import junit.framework.TestCase;
> public class TestJGroups extends TestCase {
>     /**
>      * Tests the receiveLocalMessages feature on multiplex
>      * channels.
>      * 
>      * <h2>Course of action</h2>
>      * <ol>
>      *   <li>Creates tow physical channels</li>
>      *   <li>For each physical channel a mux channel is created</li>
>      *   <li>Receive Local messages is turned off on the mux channels</li>
>      *   <li>Local address has to be set manually after connecting the physical channels (This may be done automatically)</li>
>      *   <li>Message is sent from the first mux to the second mux channel</li>
>      * </ol>
>      * 
>      * @throws Exception
>      */
>     public void testSharedTransport() throws Exception
>     {
>         MBeanServer mbeanserver = MBeanServerFactory.createMBeanServer("testserver");
>         org.jgroups.jmx.JChannel channel1 = new org.jgroups.jmx.JChannel();
>         channel1.setClusterConfig(getConfig("singletonA"));
>         channel1.setObjectName("test:service=Channel");
>         channel1.create();
>         channel1.setClusterName("Cluster1");
>         channel1.start();
>         channel1.stop();
>         channel1.destroy();
>         MBeanServerFactory.releaseMBeanServer(mbeanserver);
>     }
>     
>     
>     private Element getConfig(String singletonName) throws Exception {
>         String config = 
>             "<config>                                                                           " +
>             "  <UDP mcast_recv_buf_size=\"80000\" mcast_send_buf_size=\"150000\"                " +
>             "      mcast_port=\"32233\" mcast_addr=\"228.0.0.1\"                                " +
>             "      ip_ttl=\"32\" singleton_name=\"" + singletonName + "\"/>                     " +
>             "  <PING/>                                                                          " +
>             "  <FD_SOCK/>                                                                       " +
>             "  <VERIFY_SUSPECT timeout=\"15000\"/>                                              " +
>             "  <pbcast.NAKACK gc_lag=\"50\" retransmit_timeout=\"300,600,1200,2400,48000\"/>    " +
>             "  <UNICAST timeout=\"600,1200,2000,25000\"/>                                       " +
>             "  <FRAG frag_size=\"8096\"/>                                                       " +
>             "  <pbcast.STABLE desired_avg_gossip=\"20000\" max_bytes=\"500000\"/>               " +
>             "  <pbcast.GMS print_local_addr=\"true\" join_timeout=\"60000\" shun=\"true\" />    " +
>             "</config>                                                                          ";
>         DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
>         DocumentBuilder db = dbf.newDocumentBuilder();
>         Document d = db.parse(new ByteArrayInputStream(config.getBytes()));
>         return d.getDocumentElement();
>     }
> }
> 2009-06-17 13:05:49,409 [main] ERROR - org.jgroups.jmx.JmxConfigurator - failed to unregister test:service=Channel,protocol=TP.ProtocolAdapter
> javax.management.InstanceNotFoundException: test:service=Channel,protocol=TP.ProtocolAdapter
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1010)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:354)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:527)
> 	at org.jgroups.jmx.JmxConfigurator.unregisterProtocols(JmxConfigurator.java:121)
> 	at org.jgroups.jmx.JChannel.destroy(JChannel.java:256)
> 	at com.j2fe.clustering.impl.TestJGroups.testSharedTransport(TestJGroups.java:41)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at junit.framework.TestCase.runTest(TestCase.java:154)
> 	at junit.framework.TestCase.runBare(TestCase.java:127)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 07:20:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 17 Jun 2009 07:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-993)
 InstanceNotFoundException when
 destroying jchannel (TP.ProtocolAdapter not found in MBean server)
In-Reply-To: <13853647.1245237176489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12933230.1245237656698.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472478#action_12472478 ] 

Bela Ban commented on JGRP-993:
-------------------------------

org.jgroups.jmx.JChannel has been deprecated, try this with org.jgroups.JChannel instead !

> InstanceNotFoundException when destroying jchannel (TP.ProtocolAdapter not found in MBean server)
> -------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-993
>                 URL: https://jira.jboss.org/jira/browse/JGRP-993
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.9
>         Environment: Windows
>            Reporter: Stefan Anzinger
>            Assignee: Bela Ban
>            Priority: Minor
>
> When using shared transport with org.jgroups.jmx.JChannel there occurs a javax.management.InstanceNotFoundException when destroying the cannel.
> It has no major impact as the exception is caught and not thrown outside of jgroups. Unfortunately the exception is logged as error where obviously is no error.
> See the testcase and exception:
> import java.io.ByteArrayInputStream;
> import org.w3c.dom.*;
> import javax.management.MBeanServer;
> import javax.management.MBeanServerFactory;
> import javax.xml.parsers.*;
> import junit.framework.TestCase;
> public class TestJGroups extends TestCase {
>     /**
>      * Tests the receiveLocalMessages feature on multiplex
>      * channels.
>      * 
>      * <h2>Course of action</h2>
>      * <ol>
>      *   <li>Creates tow physical channels</li>
>      *   <li>For each physical channel a mux channel is created</li>
>      *   <li>Receive Local messages is turned off on the mux channels</li>
>      *   <li>Local address has to be set manually after connecting the physical channels (This may be done automatically)</li>
>      *   <li>Message is sent from the first mux to the second mux channel</li>
>      * </ol>
>      * 
>      * @throws Exception
>      */
>     public void testSharedTransport() throws Exception
>     {
>         MBeanServer mbeanserver = MBeanServerFactory.createMBeanServer("testserver");
>         org.jgroups.jmx.JChannel channel1 = new org.jgroups.jmx.JChannel();
>         channel1.setClusterConfig(getConfig("singletonA"));
>         channel1.setObjectName("test:service=Channel");
>         channel1.create();
>         channel1.setClusterName("Cluster1");
>         channel1.start();
>         channel1.stop();
>         channel1.destroy();
>         MBeanServerFactory.releaseMBeanServer(mbeanserver);
>     }
>     
>     
>     private Element getConfig(String singletonName) throws Exception {
>         String config = 
>             "<config>                                                                           " +
>             "  <UDP mcast_recv_buf_size=\"80000\" mcast_send_buf_size=\"150000\"                " +
>             "      mcast_port=\"32233\" mcast_addr=\"228.0.0.1\"                                " +
>             "      ip_ttl=\"32\" singleton_name=\"" + singletonName + "\"/>                     " +
>             "  <PING/>                                                                          " +
>             "  <FD_SOCK/>                                                                       " +
>             "  <VERIFY_SUSPECT timeout=\"15000\"/>                                              " +
>             "  <pbcast.NAKACK gc_lag=\"50\" retransmit_timeout=\"300,600,1200,2400,48000\"/>    " +
>             "  <UNICAST timeout=\"600,1200,2000,25000\"/>                                       " +
>             "  <FRAG frag_size=\"8096\"/>                                                       " +
>             "  <pbcast.STABLE desired_avg_gossip=\"20000\" max_bytes=\"500000\"/>               " +
>             "  <pbcast.GMS print_local_addr=\"true\" join_timeout=\"60000\" shun=\"true\" />    " +
>             "</config>                                                                          ";
>         DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
>         DocumentBuilder db = dbf.newDocumentBuilder();
>         Document d = db.parse(new ByteArrayInputStream(config.getBytes()));
>         return d.getDocumentElement();
>     }
> }
> 2009-06-17 13:05:49,409 [main] ERROR - org.jgroups.jmx.JmxConfigurator - failed to unregister test:service=Channel,protocol=TP.ProtocolAdapter
> javax.management.InstanceNotFoundException: test:service=Channel,protocol=TP.ProtocolAdapter
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1010)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:354)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:527)
> 	at org.jgroups.jmx.JmxConfigurator.unregisterProtocols(JmxConfigurator.java:121)
> 	at org.jgroups.jmx.JChannel.destroy(JChannel.java:256)
> 	at com.j2fe.clustering.impl.TestJGroups.testSharedTransport(TestJGroups.java:41)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at junit.framework.TestCase.runTest(TestCase.java:154)
> 	at junit.framework.TestCase.runBare(TestCase.java:127)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 07:33:08 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 17 Jun 2009 07:33:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-969) TestNG: enable
 OverlappingMergeTest.testOverlappingMergeWithABC()
In-Reply-To: <2800475.1241011008031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23630165.1245238388715.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-969.
---------------------------

    Resolution: Done


> TestNG: enable OverlappingMergeTest.testOverlappingMergeWithABC()
> -----------------------------------------------------------------
>
>                 Key: JGRP-969
>                 URL: https://jira.jboss.org/jira/browse/JGRP-969
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> This test is currently disabled as it depends on MERGE4

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 07:53:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 17 Jun 2009 07:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1653) specify the
 management attribute as lower-cased in management messages
In-Reply-To: <2107452.1244817716743.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33350873.1245239636523.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1653.
------------------------------------

    Resolution: Done
      Assignee: Jeff Mesnil  (was: Tim Fox)


fixed in the trunk

> specify the management attribute as lower-cased in management messages
> ----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1653
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1653
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> to be more consistent with Java conventions, the user should be able to specify management attribute lower-cased when sending
> management message with ManagementHelper.putAttribute() method.
> E.g. to retrieve the value of the QueueContrlol's messageCount, the user will call ManagementHelper.putAttribute(msg, res, "messageCount") and no longer  ManagementHelper.putAttribute(msg, res, "MessageCount")

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 07:53:57 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 17 Jun 2009 07:53:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5691538.1245239637033.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472489#action_12472489 ] 

Howard Gao commented on JBMESSAGING-1657:
-----------------------------------------

The test does not always fail, sometimes it is ok.
My observation:

1. client connects to node1, whenever a consumer is created, node1 will tell node2 to do something (in case of topic, node2 will add a binding accordingly). whenever a consumer is closed, node1 will tell node2 to remove the binding. This is achieved through jgroups.

2. when node1 is killed, client failover to node 2 and continue the operation. node2 will get notification of node1's death and do server side failover.
if client requests come in after node1's death but before node2 get notified, node2 still keeps the node1 in its cluster view, so it will try to tell node1 and expect response. But in fact node1 is already dead, so it will throw the exception.

3. actually if we kill node2, there is still a chance to get the same error. 

I'll try to figure out how to fix it and update soon.


> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 08:58:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 17 Jun 2009 08:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21900304.1245243536677.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472499#action_12472499 ] 

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

I'm starting to look at the details of the implementation. There are three cvs repos I cound with 2.8 associated with them:

HEAD -> 2.8.Beta1
Branch_JGroups_2_8_LogicalAddresses
Branch_2_8_temp

which one should changes be applied to? I assume HEAD?





> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 09:19:56 2009
From: jira-events at lists.jboss.org (Emanuele Fabbri (JIRA))
Date: Wed, 17 Jun 2009 09:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-354) jPDL - element "main"
 is not known in the jpdl-4.0.xsd schema
Message-ID: <13366315.1245244796998.JavaMail.jira@cloud.prod.atl2.jboss.com>

jPDL - element "main" is not known in the jpdl-4.0.xsd schema
-------------------------------------------------------------

                 Key: GPD-354
                 URL: https://jira.jboss.org/jira/browse/GPD-354
             Project: JBoss jBPM GPD
          Issue Type: Patch
          Components: jpdl
    Affects Versions: jBPM jPDL Designer 4.0.0.CR1
         Environment: Eclipse Ganymede 3.4.2 Build id: M20090211-1700
            Reporter: Emanuele Fabbri
            Assignee: Koen Aers


If I try to validate my jPDL with the schema that I get from the latest release of jBPM (4.0CR1) Eclipse return an error about the "mail" element.

This kind of element is also not availble by the Eclipse plug-in.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 09:27:56 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 17 Jun 2009 09:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7030) Avoid unnecessary
 class scanning for annotations during startup
Message-ID: <6125412.1245245276439.JavaMail.jira@cloud.prod.atl2.jboss.com>

Avoid unnecessary class scanning for annotations during startup
---------------------------------------------------------------

                 Key: JBAS-7030
                 URL: https://jira.jboss.org/jira/browse/JBAS-7030
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Deployers
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Scott Marlow
            Assignee: Scott Marlow
            Priority: Minor
             Fix For: JBossAS-6.0.0.Alpha1


There are a few things that we can do to avoid unnecessary scanning of classes for annotations.  This Jira is about exploring our options and making the changes that make sense.  

More context is in email thread http://lists.jboss.org/pipermail/jboss-development/2009-June/014537.html



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 09:46:56 2009
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Wed, 17 Jun 2009 09:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31175118.1245246416581.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472511#action_12472511 ] 

Justin Bertram commented on JBMESSAGING-1657:
---------------------------------------------

I have also seen the test succeed on occasion.  This is definitely an issue of timing.  The shorter the "sleep" in the client the more easy the problem is to produce.

> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 10:18:07 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 17 Jun 2009 10:18:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7018) Upgrade EJB3 to
	1.1.7
In-Reply-To: <25050850.1245054836512.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21476565.1245248287967.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-7018.
--------------------------------

    Resolution: Done


Tested against a local hudson run. No regressions. 

Done in r90332.


> Upgrade EJB3 to 1.1.7
> ---------------------
>
>                 Key: JBAS-7018
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7018
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Update the AS to use the newly released EJB3 1.1.7 version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 10:18:07 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 17 Jun 2009 10:18:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-193) Provide a
 extended
 DeploymentVisitor which can be used for filtering out deployers
In-Reply-To: <10118475.1245157136971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27831389.1245248287829.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBDEPLOY-193.
-----------------------------------

    Fix Version/s:  JBDEPLOY-2.2.x
       Resolution: Done


http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-spi/src/main/java/org/jboss/deployers/spi/deployer/helpers/ExtendedDeploymentVisitor.java is now available and can be used when the deployer knows the attachment name and type it is interested within an unit.

> Provide a extended DeploymentVisitor which can be used for filtering out deployers
> ----------------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-193
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-193
>             Project: JBoss Deployers
>          Issue Type: Feature Request
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For:  JBDEPLOY-2.2.x
>
>
> The AbstractRealDeployerWithInput currently relies on a DeploymentVisitor for filtering out deployers while processing out a deployment unit. The DeploymentVisitor is responsible for specifying the "type" of attachment to  look for, in the unit, to decide whether the unit can be processed by the deployer. There are 2 short-comings with the current DeploymentVisitor:
> 1) A unit can have multiple attachments of the same type - This effectively means a deployer cannot specify which out of these n attachments, is it interested in. This results in the deployer being called multiple times for the same unit.
> 2) Because the AbstractRealDeployerWithInput relies on the type of the attachment, it is expensive:
> protected <U> void deploy(DeploymentUnit unit, DeploymentVisitor<U> visitor) throws DeploymentException
>    {
>       if (visitor == null)
>          throw new IllegalArgumentException("Null visitor.");
>       List<U> visited = new ArrayList<U>();
>       try
>       {
>          Set<? extends U> deployments = unit.getAllMetaData(visitor.getVisitorType());
> ...
> unit.getAllMetaData internally iterates over all attachments to create collection of eligible attachments.
> To improve this, an ExtendedDeploymentVisitor can be introduced which allows for a deployer to register itself for a specific attachment with name and the corresponding type of the attachment. A new deployer can then use this ExtendedDeploymentVisitor to efficiently process the deployment unit.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 10:29:08 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 17 Jun 2009 10:29:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-6777) 'interleaving' prop
 on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33031737.1245248948609.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened JBAS-6777:
--------------------------------



Using the EAP branch r90329, I'm still seeing the interleaving prop always having a value of false, for new ds.xml files that contain the interleaving element, as well as after I've updated the prop's value to true via the Profile Service. Did you forget to check the fix into the EAP branch?


> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:03:56 2009
From: jira-events at lists.jboss.org (Marek Posolda (JIRA))
Date: Wed, 17 Jun 2009 11:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2424) Exception while
 calling removePublicRenderParameter on javax.portlet.actionResponse
In-Reply-To: <21497204.1245251036629.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23236751.1245251036969.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Posolda updated JBPORTAL-2424:
------------------------------------

    Attachment: coordination-exception.png


> Exception while calling removePublicRenderParameter on javax.portlet.actionResponse
> -----------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2424
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2424
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.7.3 Final
>         Environment: Ubuntu linux,
> Sun Java 1.5.0_16,
> JBoss 4.3.2.GA with JBoss Portal 2.7.2 - branch
>            Reporter: Marek Posolda
>         Attachments: coordination-exception.png
>
>
> Calling of method removePublicRenderParameter on javax.portlet.ActionResponse doesn't work correctly if you try to call method on some previously saved parameter. Problem can be easily simulated by trying this scenario (portal-coordination-samples should be deployed):
> 1) Go to http://localhost:8080/portal/portal/default/Coordination+Samples/Parameters+-+Implicit
> 2) Add value "Some value" to parameter "daa1" in PublicParametersPortletWindow1. Click to "Update" button.
> 3) Click to the text field "daa1" and delete the value "Some value" (not click to "Remove" link but delete the value directly in text field). Click to "Update" button.
> 4) You can see Tomcat page with 500 code. Screenshot with exception attached. This exception on it:
> java.lang.IllegalArgumentException: Array must not be zero length
>   org.jboss.portal.common.util.ParameterMap$ValueConverter.getInternal(ParameterMap.java:431)
>   org.jboss.portal.common.util.ParameterMap$ValueConverter.getInternal(ParameterMap.java:406)
>   org.jboss.portal.common.util.AbstractTypedMap$Converter$4.transform(AbstractTypedMap.java:137)
>   org.jboss.portal.common.util.AbstractTypedMap.put(AbstractTypedMap.java:239)
>   org.jboss.portal.common.util.ParameterMap.setValues(ParameterMap.java:245)
>   org.jboss.portal.core.portlet.PortletRequestEncoder.configure(PortletRequestEncoder.java:208)
>   org.jboss.portal.core.portlet.PortletRequestEncoder.encodeRender(PortletRequestEncoder.java:169)
>   org.jboss.portal.core.model.portal.PortalObjectURLFactory.doMapping(PortalObjectURLFactory.java:168)
>   org.jboss.portal.core.controller.command.mapper.DelegatingURLFactoryService.doMapping(DelegatingURLFactoryService.java:68)
>   org.jboss.portal.core.controller.ControllerContext.renderURL(ControllerContext.java:171)
>   org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:62)
>   org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:70)
>   org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:315)
>   org.jboss.portal.core.controller.Controller.processCommand(Controller.java:303)
>    org.jboss.portal.core.controller.Controller.handle(Controller.java:261)
>   org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
>   org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:68)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.PortalContextPathInterceptor.invoke(PortalContextPathInterceptor.java:45)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:196)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.server.aspects.server.SignOutInterceptor.invoke(SignOutInterceptor.java:98)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.IdentityCacheInterceptor.invoke(IdentityCacheInterceptor.java:68)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>    org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>   org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>    org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>   org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:69)
>   org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:130)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
>   org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:252)
>    javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>   org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:03:56 2009
From: jira-events at lists.jboss.org (Marek Posolda (JIRA))
Date: Wed, 17 Jun 2009 11:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2424) Exception while
 calling removePublicRenderParameter on javax.portlet.actionResponse
Message-ID: <21497204.1245251036629.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exception while calling removePublicRenderParameter on javax.portlet.actionResponse
-----------------------------------------------------------------------------------

                 Key: JBPORTAL-2424
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2424
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.7.3 Final
         Environment: Ubuntu linux,
Sun Java 1.5.0_16,
JBoss 4.3.2.GA with JBoss Portal 2.7.2 - branch
            Reporter: Marek Posolda
         Attachments: coordination-exception.png

Calling of method removePublicRenderParameter on javax.portlet.ActionResponse doesn't work correctly if you try to call method on some previously saved parameter. Problem can be easily simulated by trying this scenario (portal-coordination-samples should be deployed):

1) Go to http://localhost:8080/portal/portal/default/Coordination+Samples/Parameters+-+Implicit

2) Add value "Some value" to parameter "daa1" in PublicParametersPortletWindow1. Click to "Update" button.

3) Click to the text field "daa1" and delete the value "Some value" (not click to "Remove" link but delete the value directly in text field). Click to "Update" button.

4) You can see Tomcat page with 500 code. Screenshot with exception attached. This exception on it:

java.lang.IllegalArgumentException: Array must not be zero length
  org.jboss.portal.common.util.ParameterMap$ValueConverter.getInternal(ParameterMap.java:431)
  org.jboss.portal.common.util.ParameterMap$ValueConverter.getInternal(ParameterMap.java:406)
  org.jboss.portal.common.util.AbstractTypedMap$Converter$4.transform(AbstractTypedMap.java:137)
  org.jboss.portal.common.util.AbstractTypedMap.put(AbstractTypedMap.java:239)
  org.jboss.portal.common.util.ParameterMap.setValues(ParameterMap.java:245)
  org.jboss.portal.core.portlet.PortletRequestEncoder.configure(PortletRequestEncoder.java:208)
  org.jboss.portal.core.portlet.PortletRequestEncoder.encodeRender(PortletRequestEncoder.java:169)
  org.jboss.portal.core.model.portal.PortalObjectURLFactory.doMapping(PortalObjectURLFactory.java:168)
  org.jboss.portal.core.controller.command.mapper.DelegatingURLFactoryService.doMapping(DelegatingURLFactoryService.java:68)
  org.jboss.portal.core.controller.ControllerContext.renderURL(ControllerContext.java:171)
  org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:62)
  org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:70)
  org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:315)
  org.jboss.portal.core.controller.Controller.processCommand(Controller.java:303)
   org.jboss.portal.core.controller.Controller.handle(Controller.java:261)
  org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
  org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:68)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.core.aspects.server.PortalContextPathInterceptor.invoke(PortalContextPathInterceptor.java:45)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:196)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.server.aspects.server.SignOutInterceptor.invoke(SignOutInterceptor.java:98)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.core.aspects.server.IdentityCacheInterceptor.invoke(IdentityCacheInterceptor.java:68)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
  org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
   org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
  org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
  org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
   org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
  org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
  org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
  org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
  org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:69)
  org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:130)
  org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
  org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
  org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:252)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
  org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:14:08 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 17 Jun 2009 11:14:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7024) results of
 list*Messages methods
 of Queues and Topics have wrong meta type definition
In-Reply-To: <744707.1245166676454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15557087.1245251648174.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark reassigned JBAS-7024:
-----------------------------------

    Assignee: Scott M Stark  (was: Jason T. Greene)


> results of list*Messages methods of Queues and Topics have wrong meta type definition
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-7024
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7024
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBAPP_5_0 rev90256
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Critical
>         Attachments: JBAS-7024.patch
>
>
> The MessageListMapper used to define the meta types on list*Messages() methods for Queues and Topics advertises that the resulting type will be:
> CollectionMetaType[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> however the meta type of the actual meta values obtained using collectionValue.getElements() is advertised as:
> MapCompositeValue[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> This discrepancy is affecting the admin console, Jopr and JON because the meta values values have different type than the advertised meta type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:23:57 2009
From: jira-events at lists.jboss.org (Andy Goldstein (JIRA))
Date: Wed, 17 Jun 2009 11:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24040960.1245252237187.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472542#action_12472542 ] 

Andy Goldstein commented on JBMESSAGING-1657:
---------------------------------------------

FYI this is not limited to co-located JBoss Messaging servers & JMS client.  We've had this happen when JBoss Messaging was on 1 machine, and the client was on another machine.

Our test case was slightly different from Justin's (which aligns with #3 above):
 -Start test client connecting to node2
 -Observe client log filling up with "." 
 -Drop JBoss running on node1 (using kill -9 <pid>) 
 -Client fails with org.jboss.jms.exception.MessagingJMSException
 -Observe java.lang.IllegalStateException on node2

The difference is we had our JmsTest client connecting to the 2nd server instead of the 1st.  So the test client was always trying to connect to node2, and when we killed node1, the next attempt by the client to connect to node2 that immediately followed node1's death failed (presumably for the reason stated in #2 above).

> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:30:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 17 Jun 2009 11:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-994) JChannel: remove
 AUTO_RECONNECT and AUTO_GETSTATE options
Message-ID: <3749488.1245252656461.JavaMail.jira@cloud.prod.atl2.jboss.com>

JChannel: remove AUTO_RECONNECT and AUTO_GETSTATE options
---------------------------------------------------------

                 Key: JGRP-994
                 URL: https://jira.jboss.org/jira/browse/JGRP-994
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.0




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:30:56 2009
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Wed, 17 Jun 2009 11:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2424) Exception while
 calling removePublicRenderParameter on javax.portlet.actionResponse
In-Reply-To: <21497204.1245251036629.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10945856.1245252656752.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Prabhat Jha updated JBPORTAL-2424:
----------------------------------

        Fix Version/s: 2.7.3 Final
    Affects Version/s: 2.7.2 Final
                           (was: 2.7.3 Final)


> Exception while calling removePublicRenderParameter on javax.portlet.actionResponse
> -----------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2424
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2424
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.7.2 Final
>         Environment: Ubuntu linux,
> Sun Java 1.5.0_16,
> JBoss 4.3.2.GA with JBoss Portal 2.7.2 - branch
>            Reporter: Marek Posolda
>             Fix For: 2.7.3 Final
>
>         Attachments: coordination-exception.png
>
>
> Calling of method removePublicRenderParameter on javax.portlet.ActionResponse doesn't work correctly if you try to call method on some previously saved parameter. Problem can be easily simulated by trying this scenario (portal-coordination-samples should be deployed):
> 1) Go to http://localhost:8080/portal/portal/default/Coordination+Samples/Parameters+-+Implicit
> 2) Add value "Some value" to parameter "daa1" in PublicParametersPortletWindow1. Click to "Update" button.
> 3) Click to the text field "daa1" and delete the value "Some value" (not click to "Remove" link but delete the value directly in text field). Click to "Update" button.
> 4) You can see Tomcat page with 500 code. Screenshot with exception attached. This exception on it:
> java.lang.IllegalArgumentException: Array must not be zero length
>   org.jboss.portal.common.util.ParameterMap$ValueConverter.getInternal(ParameterMap.java:431)
>   org.jboss.portal.common.util.ParameterMap$ValueConverter.getInternal(ParameterMap.java:406)
>   org.jboss.portal.common.util.AbstractTypedMap$Converter$4.transform(AbstractTypedMap.java:137)
>   org.jboss.portal.common.util.AbstractTypedMap.put(AbstractTypedMap.java:239)
>   org.jboss.portal.common.util.ParameterMap.setValues(ParameterMap.java:245)
>   org.jboss.portal.core.portlet.PortletRequestEncoder.configure(PortletRequestEncoder.java:208)
>   org.jboss.portal.core.portlet.PortletRequestEncoder.encodeRender(PortletRequestEncoder.java:169)
>   org.jboss.portal.core.model.portal.PortalObjectURLFactory.doMapping(PortalObjectURLFactory.java:168)
>   org.jboss.portal.core.controller.command.mapper.DelegatingURLFactoryService.doMapping(DelegatingURLFactoryService.java:68)
>   org.jboss.portal.core.controller.ControllerContext.renderURL(ControllerContext.java:171)
>   org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:62)
>   org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:70)
>   org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:315)
>   org.jboss.portal.core.controller.Controller.processCommand(Controller.java:303)
>    org.jboss.portal.core.controller.Controller.handle(Controller.java:261)
>   org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
>   org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:68)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.PortalContextPathInterceptor.invoke(PortalContextPathInterceptor.java:45)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:196)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.server.aspects.server.SignOutInterceptor.invoke(SignOutInterceptor.java:98)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.IdentityCacheInterceptor.invoke(IdentityCacheInterceptor.java:68)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>    org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>   org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>    org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>   org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>   org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
>   org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:69)
>   org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:130)
>   org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>   org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
>   org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:252)
>    javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>   org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:32:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 17 Jun 2009 11:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11755311.1245252776558.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-142:
-------------------------------

    Attachment:     (was: jbweb-142.patch)


> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:34:57 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 17 Jun 2009 11:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6461596.1245252897121.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-142:
-------------------------------

    Attachment: jbweb-142.patch


Revised patch:
1) Removed extraneous space in constant name.
2) Changed constant name to org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE

> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-142.patch
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:34:56 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Wed, 17 Jun 2009 11:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26763950.1245252896843.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor reopened JBMESSAGING-1646:
--------------------------------------



This has been reported as still happening

> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>         Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>             Fix For: 2.0.0.beta2
>
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:42:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 11:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-278)
 JaasSecurityManager should not
 "swallow" LoginExceptions thrown by LoginModules
In-Reply-To: <10908665.1223380580859.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32800059.1245253376842.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated SECURITY-278:
-----------------------------------

    Fix Version/s: 2.0.4.GA


> JaasSecurityManager should not "swallow" LoginExceptions thrown by LoginModules
> -------------------------------------------------------------------------------
>
>                 Key: SECURITY-278
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-278
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.2.GA
>         Environment: JBoss AS 4.2.2.GA
>            Reporter: egor kolesnikov
>            Assignee: Anil Saldhana
>             Fix For: 2.0.4.GA
>
>
> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/jboss/src/main/org/jboss/security/plugins/JaasSecurityManager.java?annotate=1091&pathrev=1091
> JaasSecurityManager.authenticate(String beanName, Principal principal, Object credential) has the following block:
> try {
> // call login modules and authenticate
>  } catch (Exception ex) {
>     ex.printStackTrace();
>     return false;
> }
> Disregarding the fact that "ex.printStackTrace()" is a definitely bad code style, swallowing all exceptions violates the JAAS specifications regarding the fact that login modules could return false or throw LoginException if login attempt has failed (see http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/spi/LoginModule.html for details). This also affects Jboss SEAM framework which raises special event if LoginException has been thrown.
> Observed behavior:
> When LoginModule throws LoginException, JaasSecurityManager.authenticate() returns false without any additional checks.
> Expected behavior:
> When LoginModule throws LoginException, JaasSecurityManager should not catch (or should at least re-throw) it and allow the exception to reach the client code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:42:57 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 17 Jun 2009 11:42:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8127204.1245253377141.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBWEB-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472550#action_12472550 ] 

Mike Millson commented on JBWEB-142:
------------------------------------

Please apply upstream to trunk and the 2.1.x branch. I will apply to the CP branch under the linked CP Jira.

> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-142.patch
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:44:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 11:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-339) ClientLoginModule
 improperly handles SecurityAssociation stack in abort()
In-Reply-To: <7186620.1228596936975.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25913075.1245253496771.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated SECURITY-339:
-----------------------------------

      Component/s: JBossSX
    Fix Version/s: JBossSecurity_2.0.4


> ClientLoginModule improperly handles SecurityAssociation stack in abort()
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-339
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-339
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Marco Schulze
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.4
>
>
> The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the corresponding push happens in commit() [via SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)]. That means, whenever a login fails, the commit is not called (thus nothing pushed), but the abort pops out an element from the stack. This should not be done. IMHO the abort() method should look like this:
>   public boolean abort() throws LoginException
>    {
>       if( trace )
>          log.trace("abort");
>       if( restoreLoginIdentity == false )
>       {
>          // Clear the entire security association stack
>          SecurityAssociationActions.clear();         
>       }
>       return true;
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:47:07 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 11:47:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-256) Optimization:
 Precreate authorization modules in the JBossAuthorizationManager
In-Reply-To: <31000899.1214942971784.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17136609.1245253627148.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated SECURITY-256:
-----------------------------------

    Fix Version/s: JBossSecurity_2.0.4
                       (was: 2.0.3.Beta1)


> Optimization: Precreate authorization modules in the JBossAuthorizationManager
> ------------------------------------------------------------------------------
>
>                 Key: SECURITY-256
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-256
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.2.CR6
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.4
>
>
> The JBossAuthorizationManager should have initialization steps to precreate the authorization modules if the configuration is available for the security domain.  There needs to be an external mechanism to clear the authorization modules.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:48:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 11:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-255)
 IdentityLoginModule Incomplete
 password-stacking useFirstPass implementation
In-Reply-To: <4221409.1214820452243.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16075556.1245253736656.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated SECURITY-255:
-----------------------------------

    Fix Version/s: JBossSecurity_2.0.4
                       (was: 2.0.3.Beta2)
         Assignee: Anil Saldhana  (was: Darran Lofthouse)


> IdentityLoginModule Incomplete password-stacking useFirstPass implementation
> ----------------------------------------------------------------------------
>
>                 Key: SECURITY-255
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-255
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.2.CR6
>            Reporter: Darran Lofthouse
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.4
>
>
> The IdentityLoginModule has got an incomplete useFirstPass implementation.
> The login() method does start with: -
>   if( super.login() == true )
>          return true;
> To skip login if useFirstPass is set and authentication has already occurred.
> However at the end of login() setting the principal in the shared state map should only happen if useFirstPass was set.  
> Also for this to work a credential also needs to be stored in the sharedStateMap otherwise other modules will assume authentication has not occurred.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 11:48:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 11:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-101)
 JBossAuthorizationManager needs to use cache to speed up
In-Reply-To: <13553682.1197617811738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12921128.1245253736819.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated SECURITY-101:
-----------------------------------

    Fix Version/s:     (was: 2.0.3.Beta2)


> JBossAuthorizationManager needs to use cache to speed up
> --------------------------------------------------------
>
>                 Key: SECURITY-101
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-101
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.2-BETA
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>
> There is a need for a CachePolicy.  Methods like getCurrentRoles() need to speed up a bit.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:03:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 17 Jun 2009 12:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7031) make JMX invoker,
 jmx-console, 
 admin-console, and remote access to Profile Service all use the same
 security domain
Message-ID: <112800.1245254636508.JavaMail.jira@cloud.prod.atl2.jboss.com>

make JMX invoker, jmx-console, admin-console, and remote access to Profile Service all use the same security domain
-------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7031
                 URL: https://jira.jboss.org/jira/browse/JBAS-7031
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Scott M Stark
            Priority: Critical
             Fix For: JBossAS-5.2.0.Beta1


This should be done in all configurations - default, all, etc.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:06:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 17 Jun 2009 12:06:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6960) once a Topic or
 Queue has been
 stopped via the 'stop' operation, none of its operations or properties
 work, and thus it cannot be restarted using the 'start' operation
In-Reply-To: <11989891.1242832445240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25357601.1245254816635.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472551#action_12472551 ] 

Ian Springer commented on JBAS-6960:
------------------------------------

Ales told Emanuel he should have the MC update checked in by end of day Friday, June 19th.


> once a Topic or Queue has been stopped via the 'stop' operation, none of its operations or properties work, and thus it cannot be restarted using the 'start' operation
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6960
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6960
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Ian Springer
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:09:08 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:09:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-418) JBossPDP evaluate
 needs to be thread safe
In-Reply-To: <12412465.1245254948002.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23549338.1245254948137.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated SECURITY-418:
-----------------------------------

    Fix Version/s: jbossxacml_2.0.3.SP2


> JBossPDP evaluate needs to be thread safe
> -----------------------------------------
>
>                 Key: SECURITY-418
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-418
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossXACML
>    Affects Versions: jbossxacml_2.0.3.SP1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP2
>
>
> PDP evaluation method needs to be thread safe.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:09:07 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:09:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-418) JBossPDP evaluate
 needs to be thread safe
Message-ID: <12412465.1245254948002.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBossPDP evaluate needs to be thread safe
-----------------------------------------

                 Key: SECURITY-418
                 URL: https://jira.jboss.org/jira/browse/SECURITY-418
             Project: JBoss Security and Identity Management
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JBossXACML
    Affects Versions: jbossxacml_2.0.3.SP1
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana


PDP evaluation method needs to be thread safe.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:22:59 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 17 Jun 2009 12:22:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3766163.1245255779562.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-142:
-------------------------------

    Attachment: jbweb-142.patch


Fixed tab/space issue I noticed when applying to patch branch.

> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-142.patch
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:22:58 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Wed, 17 Jun 2009 12:22:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17844984.1245255778861.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-142:
-------------------------------

    Attachment:     (was: jbweb-142.patch)


> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-142.patch
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:22:59 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 17 Jun 2009 12:22:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-937) MERGE4: get rid of
 shunning and use only merging (getting rid of shunfests)
In-Reply-To: <27983172.1237998262778.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32324151.1245255779348.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-937.
---------------------------

    Resolution: Done


> MERGE4: get rid of shunning and use only merging (getting rid of shunfests)
> ---------------------------------------------------------------------------
>
>                 Key: JGRP-937
>                 URL: https://jira.jboss.org/jira/browse/JGRP-937
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: udp-2.6.xml
>
>
> If we have FD_ALL plus shunning, the following scenario can happen:
> - A network partition with subgroups {A} and {B,C,D,E,F,G}
> - The partition heals
> - A gets heartbeats from all members of the 2nd subgroup
> - A's FD_ALL.shun will shun all members of the 2nd subgroup !
> - And vice versa, this leads to a shunfest and large clusters might never merge back again
> SOLUTION:
> - Get rid of shunning (GMS.shun is false by default anyway, now also set FD/FD_ALL.shun to false)
> - MERGE4 periodically compares discovery results to its view
> (- This might be done a few times)
> - Then MERGE4 initiates a merge between all members who have differing views
> - Make sure digests get merged correctly (min/max)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:36:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-418) JBossPDP evaluate
 needs to be thread safe
In-Reply-To: <12412465.1245254948002.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13927950.1245256616581.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-418.
----------------------------------

    Resolution: Done


Added a lock to the evaluation.  Since the number of locks is low, a reentrant lock is suitable.

> JBossPDP evaluate needs to be thread safe
> -----------------------------------------
>
>                 Key: SECURITY-418
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-418
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossXACML
>    Affects Versions: jbossxacml_2.0.3.SP1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP2
>
>
> PDP evaluation method needs to be thread safe.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:36:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-419) JBossXACML
	2.0.3.SP2 Release
Message-ID: <31884338.1245256616926.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBossXACML 2.0.3.SP2 Release
----------------------------

                 Key: SECURITY-419
                 URL: https://jira.jboss.org/jira/browse/SECURITY-419
             Project: JBoss Security and Identity Management
          Issue Type: Release
      Security Level: Public (Everyone can see)
          Components: jboss-sunxacml, JBossXACML
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:36:57 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:36:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-419) JBossXACML
	2.0.3.SP2 Release
In-Reply-To: <31884338.1245256616926.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13757529.1245256617098.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated SECURITY-419:
-----------------------------------

    Fix Version/s: jbossxacml_2.0.3.SP2


> JBossXACML 2.0.3.SP2 Release
> ----------------------------
>
>                 Key: SECURITY-419
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-419
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: jboss-sunxacml, JBossXACML
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:36:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 17 Jun 2009 12:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-980) VIEW_SYNC: remove it
	from stack
In-Reply-To: <5526265.1242300529250.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <605701.1245256616760.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-980.
---------------------------

    Resolution: Done


> VIEW_SYNC: remove it from stack
> -------------------------------
>
>                 Key: JGRP-980
>                 URL: https://jira.jboss.org/jira/browse/JGRP-980
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> VIEW_SYNC is not necessary once we have MERGE4

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:40:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 17 Jun 2009 12:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-87) Started Bootstraps
 are not removed after shutdown
In-Reply-To: <19385748.1243478936539.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26968803.1245256856710.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBBOOT-87:
--------------------------------------

    Description: During shutdown, we need to remove each bootstrap that's actually been shutdown from the list.  Otherwise they'll be continually marked as "started" even during the next Server restart.  (was: During shutdown, we need to removed each bootstrap that's actually been shutdown from the list.  Otherwise they'll be continually marked as "started" even during the next Server restart.)


> Started Bootstraps are not removed after shutdown
> -------------------------------------------------
>
>                 Key: JBBOOT-87
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-87
>             Project: JBoss Bootstrap
>          Issue Type: Bug
>          Components: impl-base
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>
> During shutdown, we need to remove each bootstrap that's actually been shutdown from the list.  Otherwise they'll be continually marked as "started" even during the next Server restart.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:42:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 17 Jun 2009 12:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-532) Ant tasks not
 passing properties correctly to AS dist build
In-Reply-To: <17089570.1245161096601.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17919277.1245256976722.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier closed JBBUILD-532.
-----------------------------

    Resolution: Done


> Ant tasks not passing properties correctly to AS dist build
> -----------------------------------------------------------
>
>                 Key: JBBUILD-532
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-532
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - Maint 2009
>
>
> There is a problem passing properties through the antrun plugin and then to the maven ant tasks.  One of these is not passing system properties correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:42:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 17 Jun 2009 12:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-532) Ant tasks not
 passing properties correctly to AS dist build
In-Reply-To: <17089570.1245161096601.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26786138.1245256976517.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472559#action_12472559 ] 

Paul Gier commented on JBBUILD-532:
-----------------------------------

This is fixed in r90340
http://fisheye.jboss.org/changelog/JBossAS/trunk?cs=90340

I added a snapshot version of the maven ant tasks which should be updated after the next release.

> Ant tasks not passing properties correctly to AS dist build
> -----------------------------------------------------------
>
>                 Key: JBBUILD-532
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-532
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - Maint 2009
>
>
> There is a problem passing properties through the antrun plugin and then to the maven ant tasks.  One of these is not passing system properties correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:55:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-419) JBossXACML
	2.0.3.SP2 Release
In-Reply-To: <31884338.1245256616926.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11281269.1245257756475.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-419.
----------------------------------

    Resolution: Done


> JBossXACML 2.0.3.SP2 Release
> ----------------------------
>
>                 Key: SECURITY-419
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-419
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: jboss-sunxacml, JBossXACML
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.3.SP2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:58:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-130)
 SOAPSAMLXACMLServlet:: PDP in init method
In-Reply-To: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5132848.1245257936868.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-130:
-------------------------------

    Summary: SOAPSAMLXACMLServlet:: PDP in init method   (was: SOAPSAMLXACMLServlet:: PDP in init method and threadsafe evaluation)


> SOAPSAMLXACMLServlet:: PDP in init method 
> ------------------------------------------
>
>                 Key: JBID-130
>                 URL: https://jira.jboss.org/jira/browse/JBID-130
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 12:58:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 12:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-130)
 SOAPSAMLXACMLServlet:: PDP in init method and threadsafe evaluation
In-Reply-To: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29592829.1245257936747.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-130:
--------------------------------



PDP should be created in init method

But since the PDP evaluation is thread safe, we do not need any locking.

> SOAPSAMLXACMLServlet:: PDP in init method and threadsafe evaluation
> -------------------------------------------------------------------
>
>                 Key: JBID-130
>                 URL: https://jira.jboss.org/jira/browse/JBID-130
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 13:26:08 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 13:26:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-130) SOAPSAMLXACMLServlet::
 PDP in init method
In-Reply-To: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15646449.1245259568111.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-130.
------------------------------

    Resolution: Done


> SOAPSAMLXACMLServlet:: PDP in init method 
> ------------------------------------------
>
>                 Key: JBID-130
>                 URL: https://jira.jboss.org/jira/browse/JBID-130
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 13:43:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 17 Jun 2009 13:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-209) jboss-metadata
 trunk test compilation fails in JDK5
Message-ID: <9131641.1245260636508.JavaMail.jira@cloud.prod.atl2.jboss.com>

jboss-metadata trunk test compilation fails in JDK5
---------------------------------------------------

                 Key: JBMETA-209
                 URL: https://jira.jboss.org/jira/browse/JBMETA-209
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.0.2.Beta2


[INFO] Compilation failure
/home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
symbol  : method stringPropertyNames()
location: class java.util.Properties

/home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
symbol  : method stringPropertyNames()
location: class java.util.Properties

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 13:43:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 17 Jun 2009 13:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7024) results of
 list*Messages methods
 of Queues and Topics have wrong meta type definition
In-Reply-To: <744707.1245166676454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19599636.1245260636693.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-7024.
---------------------------------

    Resolution: Done


I have applied the patch to produce a CompositeValueSupport, but the existing
MapCompositeValue is a CompositeValue and should be seen as consistent with the declared CompositeMetaType.

> results of list*Messages methods of Queues and Topics have wrong meta type definition
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-7024
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7024
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBAPP_5_0 rev90256
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Critical
>         Attachments: JBAS-7024.patch
>
>
> The MessageListMapper used to define the meta types on list*Messages() methods for Queues and Topics advertises that the resulting type will be:
> CollectionMetaType[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> however the meta type of the actual meta values obtained using collectionValue.getElements() is advertised as:
> MapCompositeValue[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> This discrepancy is affecting the admin console, Jopr and JON because the meta values values have different type than the advertised meta type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 13:45:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 17 Jun 2009 13:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7024) results of
 list*Messages methods
 of Queues and Topics have wrong meta type definition
In-Reply-To: <744707.1245166676454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27811850.1245260756564.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark updated JBAS-7024:
--------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> results of list*Messages methods of Queues and Topics have wrong meta type definition
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-7024
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7024
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBAPP_5_0 rev90256
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: JBAS-7024.patch
>
>
> The MessageListMapper used to define the meta types on list*Messages() methods for Queues and Topics advertises that the resulting type will be:
> CollectionMetaType[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> however the meta type of the actual meta values obtained using collectionValue.getElements() is advertised as:
> MapCompositeValue[ImmutableCompositeMetaType["JMSMessageID" = SimpleMetaType.STRING, "JMSCorrelationID" = SimpleMetaType.STRING, "JMSTimestamp" = SimpleMetaType.LONG]]
> This discrepancy is affecting the admin console, Jopr and JON because the meta values values have different type than the advertised meta type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 13:45:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 17 Jun 2009 13:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-209) jboss-metadata
 trunk test compilation fails in JDK5
In-Reply-To: <9131641.1245260636508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16389016.1245260756719.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBMETA-209.
----------------------------------------

    Resolution: Done


> jboss-metadata trunk test compilation fails in JDK5
> ---------------------------------------------------
>
>                 Key: JBMETA-209
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-209
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.0.2.Beta2
>
>
> [INFO] Compilation failure
> /home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
> symbol  : method stringPropertyNames()
> location: class java.util.Properties
> /home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
> symbol  : method stringPropertyNames()
> location: class java.util.Properties

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:01:56 2009
From: jira-events at lists.jboss.org (Scott Clasen (JIRA))
Date: Wed, 17 Jun 2009 15:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
Message-ID: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>

Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
--------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1658
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta2
         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.


            Reporter: Scott Clasen
            Assignee: Tim Fox


Clocks on the 2 boxes are in sync so notice the times in the log entries below.

PRIMARY

13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
...MESSAGE REPEATS TILL SERVER KILLED...

=======================================================================================================================================
SECONDARY


14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
...MESSAGE REPEATS TILL SERVER KILLED...


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:03:56 2009
From: jira-events at lists.jboss.org (Scott Clasen (JIRA))
Date: Wed, 17 Jun 2009 15:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10203119.1245265436858.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Clasen updated JBMESSAGING-1658:
--------------------------------------

    Attachment: threadDumps.txt


Thread dumps of both servers

> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:19:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Wed, 17 Jun 2009 15:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <19505031.1245266396893.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene moved EMBJOPR-194 to JBAS-7032:
-----------------------------------------------

              Project: JBoss Application Server  (was: Embedded Jopr)
                  Key: JBAS-7032  (was: EMBJOPR-194)
          Component/s: Deployers
                           (was: Core Infrastructure)
    Affects Version/s:     (was: 1.2)
             Security: Public


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Ian Springer
>            Priority: Minor
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:22:02 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Wed, 17 Jun 2009 15:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <27866982.1245266522046.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene reassigned JBAS-7032:
-------------------------------------

    Assignee: Scott Marlow  (was: Ian Springer)


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Scott Marlow
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:22:02 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Wed, 17 Jun 2009 15:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <24349631.1245266522427.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472585#action_12472585 ] 

Jason T. Greene commented on JBAS-7032:
---------------------------------------

If this problem happens during hot deploy then its likely a general AS issue. I have moved it to the AS project

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Scott Marlow
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:22:02 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Wed, 17 Jun 2009 15:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <9669355.1245266522224.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBAS-7032:
----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
         Priority: Major  (was: Minor)


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Scott Marlow
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:23:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Wed, 17 Jun 2009 15:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <10262616.1245266636682.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472586#action_12472586 ] 

Jason T. Greene commented on JBAS-7032:
---------------------------------------

It looks like classloading isn't there...

Caused by: java.lang.IllegalArgumentException: No module in deployment unit's hierarchy: vfszip:/usr
/local/jboss/jboss-5.1.0.GA/server/default/deploy/ImageServer.ear/imageserver-ejb.jar/
	at org.jboss.deployers.vfs.plugins.annotations.AnnotationEnvironmentDeployer.deploy(AnnotationEnvir
onmentDeployer.java:229)
	at org.jboss.deployers.vfs.plugins.annotations.AnnotationEnvironmentDeployer.deploy(AnnotationEnvir
onmentDeployer.java:48)
	at org.jboss.deployers.vfs.spi.deployer.AbstractOptionalVFSRealDeployer.deploy(AbstractOptionalVFSR
ealDeployer.java:57)
	at org.jboss.deployers.spi.deployer.helpers.AbstractOptionalRealDeployer.internalDeploy(AbstractOpt
ionalRealDeployer.java:74)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:5
0)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	... 38 more


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Scott Marlow
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:29:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Wed, 17 Jun 2009 15:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-210) Validation errors
 in some jboss-___.5_x.xsd files
Message-ID: <21174263.1245266996482.JavaMail.jira@cloud.prod.atl2.jboss.com>

Validation errors in some jboss-___.5_x.xsd files
-------------------------------------------------

                 Key: JBMETA-210
                 URL: https://jira.jboss.org/jira/browse/JBMETA-210
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: Eclipse 3.4.2/WebToolsPlatform 3.0.4
            Reporter: Wolfgang Knauf
            Assignee: Alexey Loubyansky


Some more schema definitions for 5.0/5.1 contain validation errors (which will raise validation errors if building instances in Eclipse). The problem is that includes/imports don't point to the web locations.
The same issue arose for jboss-5.1.xsd: https://jira.jboss.org/jira/browse/JBMETA-200

jboss-web_5_1.xsd:

   <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>
   <xsd:include schemaLocation="jboss-common_5_1.xsd"/>

Change to:
   <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>
   <xsd:include schemaLocation="http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd"/>

===================    

jboss-ds_5_0.xsd:
   <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>
   <xsd:include schemaLocation="jboss-common_5_1.xsd"/>

Change to:

   <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>
   <xsd:include schemaLocation="http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd"/>
   
===================    

jboss-client_5_1.xsd
   <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>
   <xsd:include schemaLocation="jboss-common_5_1.xsd"/>

Change to:

   <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>
   <xsd:include schemaLocation="http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd"/>
   


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:38:08 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Wed, 17 Jun 2009 15:38:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <29107786.1245267488399.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472590#action_12472590 ] 

John Ament commented on JBAS-7032:
----------------------------------

Classloading on what exactly?  BTW, since it happens in both hot and cold deployments (e.g. copy file to deploy while app server off) it seemed like more of a JOPR issue.  

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Scott Marlow
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:41:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 15:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7033) Upgrade to
	JBossXACML 2.0.3.SP2
Message-ID: <13425312.1245267716521.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade to JBossXACML 2.0.3.SP2 
--------------------------------

                 Key: JBAS-7033
                 URL: https://jira.jboss.org/jira/browse/JBAS-7033
             Project: JBoss Application Server
          Issue Type: Component Upgrade
      Security Level: Public (Everyone can see)
          Components: Security
            Reporter: Anil Saldhana
            Assignee: Stefan Guilhen
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


Upgrade to JBossXACML 2.0.3.SP2

Branch_5_x, trunk and the branch corresponding to EAP5 (find out what branch is that).

Just update the component/pom.xml

Run the   ant   tests-security-basic-unit test target and see if there are regressions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:43:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Wed, 17 Jun 2009 15:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7034) Outdated/missing
 schema files on website
Message-ID: <15960137.1245267836412.JavaMail.jira@cloud.prod.atl2.jboss.com>

Outdated/missing schema files on website
----------------------------------------

                 Key: JBAS-7034
                 URL: https://jira.jboss.org/jira/browse/JBAS-7034
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Wolfgang Knauf


Some xsd files are missing or are outdated at http://www.jboss.org/j2ee/schema/

Please update from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/):

jboss-ds_5_0.xsd (missing)
jboss-web_5_1.xsd (missing)
jboss_common_5_1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.0.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-185 )
(some still do not validate because of invalid schema locations, so they must be updated again if https://jira.jboss.org/jira/browse/JBMETA-210 is fixed)

bean-deployer_1_0.xsd (missing)
bean-deployer_2_0.xsd (missing)
jboss-beans-common_2_0.xsd (missing)
policy_1_0.xsd (missing)
Note: they do not validate, too (invalid schema locations, and a (maybe false) validation error), but they should be available on the website anyway.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:45:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 15:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7033) Upgrade to
	JBossXACML 2.0.3.SP2
In-Reply-To: <13425312.1245267716521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29437119.1245267956577.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472592#action_12472592 ] 

Anil Saldhana commented on JBAS-7033:
-------------------------------------

JBPAPP_5_0/

> Upgrade to JBossXACML 2.0.3.SP2 
> --------------------------------
>
>                 Key: JBAS-7033
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7033
>             Project: JBoss Application Server
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Upgrade to JBossXACML 2.0.3.SP2
> Branch_5_x, trunk and the branch corresponding to EAP5 (find out what branch is that).
> Just update the component/pom.xml
> Run the   ant   tests-security-basic-unit test target and see if there are regressions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:55:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 17 Jun 2009 15:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6777) 'interleaving' prop
 on connection
 factories and datasources is always null, even when underlying ds.xml file
 contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10903454.1245268556692.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark updated JBAS-6777:
--------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238330


See the forum thread for why this property cannot be true on a non-XA factory

> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 15:57:56 2009
From: jira-events at lists.jboss.org (Jonathon Leibundguth (JIRA))
Date: Wed, 17 Jun 2009 15:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2114) Drools hangs
 with deadlock
 after it has initialized a rule (in multithreaded environment)
In-Reply-To: <30331207.1244203927899.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24259987.1245268676653.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472597#action_12472597 ] 

Jonathon Leibundguth commented on JBRULES-2114:
-----------------------------------------------

Believe I am seeing this same deadlock issue in the 5.0 release.

> Drools hangs with deadlock after it has initialized a rule (in multithreaded environment)
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2114
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2114
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 4.0.6
>            Reporter: Andrey Nechaev
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: patch-AbstractRuleBase
>
>
> Here is a scenario when drools core hangs with a deadlock:
> Suppose we heve a rule throwing an exception in the RHS. 
> So, if:
> 1. Thread A updates the Rule Base with the rule 
> 2. The rule fires (current thread is Thread A)
> 3. Rule's RHS throws an exception (still having Thread A as current)
> 4. Thread B tries to update the Rule Base or the Working Memory (for example, the Thread B inserts a fact)
> in such a case the Thread B falls into infinite wait() loop.
> Here is the test case showing such a behavior:
> package com.test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> public class DroolsTest2 {
> 	private final static String rule = "" + 
> 	"package test\n" +
> 	"import com.test.DroolsTest2;\n" +
> 	"rule test\n" +
> 		"\twhen\n" +
> 		"\tthen\n" +
> 			"\t\tDroolsTest2.fail();" +
> 	"end";
> 	
> 	private static Object sem = new Object();
> 	private static boolean seed = false;
> 	
> 	public static void main(String[] args) throws Exception {
> 		final RuleBase rb = RuleBaseFactory.newRuleBase();
> 		final WorkingMemory wm = rb.newStatefulSession();
> 		new Thread(new Runnable() {
> 			@Override
> 			public void run() {
> 				seed = false;
> 				PackageBuilder bld = new PackageBuilder();
> 				try {
> 					bld.addPackageFromDrl(new StringReader(rule));				
> 					rb.addPackage(bld.getPackage());
> 				} catch(Exception e) {					
> 				} finally {
> 					synchronized (sem) {
> 						seed = true;
> 						sem.notify();
> 					}
> 				}
> 			}
> 		}).start();
> 		Thread ins = new Thread(new Runnable() {
> 			@Override
> 			public void run() {
> 				while(!seed) {
> 					synchronized (sem) {
> 						try {
> 							sem.wait();
> 						} catch (InterruptedException e) {}
> 					}
> 				}
> 				wm.insert(new Object());
> 			}
> 		});
> 		ins.start();
> 		ins.join();
> 	}
> 	
> 	public static void fail() {
> 		throw new IllegalStateException("fail!");
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 16:00:07 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 16:00:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-420) JBoss Security
 2.0.3.SP2 Release
Message-ID: <14028107.1245268807366.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBoss Security 2.0.3.SP2 Release
--------------------------------

                 Key: SECURITY-420
                 URL: https://jira.jboss.org/jira/browse/SECURITY-420
             Project: JBoss Security and Identity Management
          Issue Type: Release
      Security Level: Public (Everyone can see)
          Components: JBossSX, Security SPI
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 16:01:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 16:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-420) JBoss Security
 2.0.3.SP2 Release
In-Reply-To: <14028107.1245268807366.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23764798.1245268916438.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated SECURITY-420:
-----------------------------------

    Fix Version/s: JBossSecurity_2.0.3.SP2


> JBoss Security 2.0.3.SP2 Release
> --------------------------------
>
>                 Key: SECURITY-420
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-420
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 16:18:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 17 Jun 2009 16:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-420) JBoss Security
 2.0.3.SP2 Release
In-Reply-To: <14028107.1245268807366.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2346242.1245269936420.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-420.
----------------------------------

    Resolution: Done


> JBoss Security 2.0.3.SP2 Release
> --------------------------------
>
>                 Key: SECURITY-420
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-420
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 16:29:56 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 17 Jun 2009 16:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7035) Help avoid unneeded
 scanning of classes for annotations by adding jboss-scanning.xml
Message-ID: <32851153.1245270596605.JavaMail.jira@cloud.prod.atl2.jboss.com>

Help avoid unneeded scanning of classes for annotations by adding jboss-scanning.xml
------------------------------------------------------------------------------------

                 Key: JBAS-7035
                 URL: https://jira.jboss.org/jira/browse/JBAS-7035
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Web Services
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Scott Marlow
            Assignee: Alessio Soldano
             Fix For: JBossAS-6.0.0.Alpha1
         Attachments: jboss-scanning.xml

Please add the attached jboss-scanning.xml file to folders:
  jbossws.sar/jbossws-management.war/META-INF
  jbossws.sar/jbossws-management.war/WEB-INF


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 16:29:56 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 17 Jun 2009 16:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7035) Help avoid unneeded
 scanning of classes for annotations by adding jboss-scanning.xml
In-Reply-To: <32851153.1245270596605.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24379987.1245270596915.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated JBAS-7035:
-------------------------------

    Attachment: jboss-scanning.xml


> Help avoid unneeded scanning of classes for annotations by adding jboss-scanning.xml
> ------------------------------------------------------------------------------------
>
>                 Key: JBAS-7035
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7035
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott Marlow
>            Assignee: Alessio Soldano
>             Fix For: JBossAS-6.0.0.Alpha1
>
>         Attachments: jboss-scanning.xml
>
>
> Please add the attached jboss-scanning.xml file to folders:
>   jbossws.sar/jbossws-management.war/META-INF
>   jbossws.sar/jbossws-management.war/WEB-INF

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 16:31:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 17 Jun 2009 16:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15366401.1245270716524.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472601#action_12472601 ] 

Tim Fox commented on JBMESSAGING-1658:
--------------------------------------

Scott, just to let you know:

I have been running two servers, on different nodes with your config, fine for 4 hours now with no errors, let's see how it is in the morning.

> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 16:59:56 2009
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Wed, 17 Jun 2009 16:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7036) Wrong server.xml may
	be loaded
Message-ID: <28044856.1245272396732.JavaMail.jira@cloud.prod.atl2.jboss.com>

Wrong server.xml may be loaded
------------------------------

                 Key: JBAS-7036
                 URL: https://jira.jboss.org/jira/browse/JBAS-7036
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Tomcat) service
    Affects Versions: JBossAS-4.2.3.GA
            Reporter: Dennis Reed
            Assignee: Remy Maucherat


JBoss AS does not specify the path to server.xml, allowing JBossWeb to choose the wrong file.

The file is only specified as "server.xml".  JBossWeb looks for ${catalina.base}/server.xml, where catalina.base is ${jboss.server.home.dir}.
If it fails to find it there (currently the normal case), it then searches the classpath for server.xml.

If there is another server.xml in ${jboss.server.home.dir}/server.xml or anywhere in the classpath, it may get used instead.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 17:12:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 17 Jun 2009 17:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2425) It should be
 possible to concatenate context path to relative URL in WSRP context
Message-ID: <27700505.1245273176369.JavaMail.jira@cloud.prod.atl2.jboss.com>

It should be possible to concatenate context path to relative URL in WSRP context
---------------------------------------------------------------------------------

                 Key: JBPORTAL-2425
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2425
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.7.2 Final
            Reporter: Chris Laprun
            Assignee: Chris Laprun
            Priority: Minor
             Fix For: 2.7.3 Final


In particular: renderResponse.encodeURL(renderRequest.getContextPath()) + "/something" should result in a valid URL in a WSRP context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 17:14:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 17 Jun 2009 17:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2426) URLTools should
 detect applet archive URLs
Message-ID: <33386362.1245273296381.JavaMail.jira@cloud.prod.atl2.jboss.com>

URLTools should detect applet archive URLs
------------------------------------------

                 Key: JBPORTAL-2426
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2426
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.7.2 Final
            Reporter: Chris Laprun
            Assignee: Chris Laprun
             Fix For: 2.7.3 Final




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 17:24:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 17 Jun 2009 17:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-2426) URLTools should
 detect applet archive URLs
In-Reply-To: <33386362.1245273296381.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15211714.1245273896431.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Laprun resolved JBPORTAL-2426.
------------------------------------

    Resolution: Done


> URLTools should detect applet archive URLs
> ------------------------------------------
>
>                 Key: JBPORTAL-2426
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2426
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.7.2 Final
>            Reporter: Chris Laprun
>            Assignee: Chris Laprun
>             Fix For: 2.7.3 Final
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 17:29:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 17 Jun 2009 17:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-522) Set properties
 related to the build environment in jar.
In-Reply-To: <20490295.1238020522431.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20416285.1245274196844.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier closed JBBUILD-522.
-----------------------------

    Resolution: Done


Fixed in r90360.

> Set properties related to the build environment in jar.
> -------------------------------------------------------
>
>                 Key: JBBUILD-522
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-522
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - Maint 2009
>
>
> It is useful to have details about the build environment contained in the maven repository.  Either in a text file or inside the deployed jar.  The most practical way to do this seems to be setting properties in the manifest that contains information about java version, OS, maven version, and svn revision.
> The java version and OS can be gathered from standard maven properties.  The svn revision can be set in a property using the buildnumber-maven-plugin.  There currently does not appear to be an easy way to record the version of maven that was used during the build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 17:29:56 2009
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 17 Jun 2009 17:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-2425) It should be
 possible to concatenate context path to relative URL in WSRP context
In-Reply-To: <27700505.1245273176369.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4770608.1245274196700.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Laprun resolved JBPORTAL-2425.
------------------------------------

    Resolution: Done


> It should be possible to concatenate context path to relative URL in WSRP context
> ---------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2425
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2425
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.7.2 Final
>            Reporter: Chris Laprun
>            Assignee: Chris Laprun
>            Priority: Minor
>             Fix For: 2.7.3 Final
>
>
> In particular: renderResponse.encodeURL(renderRequest.getContextPath()) + "/something" should result in a valid URL in a WSRP context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 19:12:56 2009
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 17 Jun 2009 19:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2127)
 KnowledgeBase.getKnowledgePackage(String str) should return null if package
 does not exist
Message-ID: <27626257.1245280376657.JavaMail.jira@cloud.prod.atl2.jboss.com>

KnowledgeBase.getKnowledgePackage(String str) should return null if package does not exist
------------------------------------------------------------------------------------------

                 Key: JBRULES-2127
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2127
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-api
            Reporter: Mark Proctor
            Assignee: Mark Proctor
             Fix For: 5.1.0.M1


currently it's returning an empty KnowledgePackage, if it does not exist, it should return null.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 19:22:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 17 Jun 2009 19:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27177999.1245280976548.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472614#action_12472614 ] 

Andrew Lee Rubinger commented on JBAS-7008:
-------------------------------------------

Are you sure EntityTestBean is an entity, not some SLSB used to test entities?  Because these metrics make no sense for entities; they're not invoked, we don't track create counts, etc.

> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 19:42:56 2009
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 17 Jun 2009 19:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2127)
 KnowledgeBase.getKnowledgePackage(String str) should return null if package
 does not exist
In-Reply-To: <27626257.1245280376657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12572348.1245282176669.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Proctor closed JBRULES-2127.
---------------------------------

    Resolution: Done


> KnowledgeBase.getKnowledgePackage(String str) should return null if package does not exist
> ------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2127
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2127
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-api
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 5.1.0.M1
>
>
> currently it's returning an empty KnowledgePackage, if it does not exist, it should return null.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 20:31:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Wed, 17 Jun 2009 20:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10519516.1245285116535.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472616#action_12472616 ] 

Jason T. Greene commented on JBAS-7008:
---------------------------------------

There are no JMX entries for EJB3 entities, since they are *not* managed by the container. I think hibernate stats is really what you are after, that is the only part of the system that knows what an entity is.

> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 20:55:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 17 Jun 2009 20:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4183452.1245286556638.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472618#action_12472618 ] 

Ian Springer commented on JBAS-7008:
------------------------------------

Yeah, my bad. EntityTestBean is indeed an SLSB. Jason, is it possible for you to use some Hibernate API to obtain the list of deployed entities and their associated deployments?


> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 22:21:56 2009
From: jira-events at lists.jboss.org (Ronn C (JIRA))
Date: Wed, 17 Jun 2009 22:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Admin Join problem
 -GMS flush by coordinator failed
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29605691.1245291716718.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472620#action_12472620 ] 

Ronn C commented on JGRP-985:
-----------------------------

I'm now using 2.6.10.merge. Will be deploying to prod soon but rather nervous about it.

> having three nodes fail at the same time.

Yes I think your guess is right, something in the coordinator must be corrupted and once failure happens on one node, it will happen to other node that wants to join.

I had tried to debug the problem and I got as far as the coordinator had received JOIN request and as part of processing the JOIN request it was trying to do a flush but flush return false as a result it doesn't generate JOIN response and add the member in. 

The code that implement flush rather hard to follow and I was hoping that there would be a document that would explain to me how flush work in algorithmic form so that it would give me a bit of context to what/where I should be looking out for. Is there such a thing? If not could you explain it to me and I'll try to debug it again. 




> Admin  Join problem -GMS flush by coordinator failed
> ----------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 17 23:17:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Wed, 17 Jun 2009 23:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-736) Create workaround for
 IBM JVM's Clas.getDeclaringClass bug
In-Reply-To: <33122186.1245199796446.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24519667.1245295076428.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAOP-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone closed JBAOP-736.
--------------------------------

    Resolution: Done


> Create workaround for IBM JVM's Clas.getDeclaringClass bug
> ----------------------------------------------------------
>
>                 Key: JBAOP-736
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-736
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>             Fix For: 2.1.2.GA
>
>
> The IBM's JVM returns null when the generated advisor's constructor invokes this.getClass().getDeclaringClass(), thus causing JBoss AOP from version 2.0 on to not work with IBM's JVM.
> The call to getDeclaringClass() needs to be replaced.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 00:32:56 2009
From: jira-events at lists.jboss.org (Calvin Lin (JIRA))
Date: Thu, 18 Jun 2009 00:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7037) JBossAS 5.x fails to
 use EJB's
 security domain in jboss.xml when the call is from web container
Message-ID: <2821553.1245299576703.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBossAS 5.x fails to use EJB's security domain in jboss.xml when the call is from web container
-----------------------------------------------------------------------------------------------

                 Key: JBAS-7037
                 URL: https://jira.jboss.org/jira/browse/JBAS-7037
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.0.1.GA
         Environment: Problem found on Windows platform
            Reporter: Calvin Lin
            Assignee: Anil Saldhana
            Priority: Critical


A degredation from JBoss 4.0.x and 4.2.x to JBoss 5.0.1.GA and JBoss 5.1.0.GA.

We noticed that the JAAS login in EJB container always picks up the Web app's security domain when the client login is originated from a web application client.  The security domain specified in EJB container's jboss.xml is always ignored in this situation.

The detailed problem description is posted on JBoss forum:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156863

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 00:49:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 00:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1646) unable to
 restart live/backup pair after clean stop
In-Reply-To: <9702944.1244654696809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24815718.1245300597131.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1646.
----------------------------------------

    Resolution: Done


Scott Clasen has opened a new issue (JBMESSAGING-1656). 

> unable to restart live/backup pair after clean stop
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1646
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1646
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>         Environment: Standalone JBM 2.0-BETA servers on  2 hosts running  RHEL 5 64 bit. JDK 1.6.0_13
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>             Fix For: 2.0.0.beta2
>
>         Attachments: jbm-configuration.xml, jbm-configuration.xml
>
>
> Unable to cleanly stop then restart a live/backup pair. I start the backup, start the live. Stop live with stop.sh, then backup with stop.sh.  Exception thrown on stopping the backup. Restart backup then live, another exception thrown in the backup.  Log snippets below.
> Start Backup--->
>  12:55:27,094 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:55:32,536 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> Start Live-->
>  12:55:53,243 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
>  12:56:04,718 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:04,770 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees live -->
>  12:56:09,169 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
>  12:56:09,221 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
>  12:56:10,778 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server is now operational 
> Live up->
>  12:56:11,233 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started
> Stop live--->
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb01d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 12:56:42,734 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 12:56:44,719 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) stopped 
> Stop Backup-->
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ ./stop.sh 
> [sclasen at nydetemb02d /hboprod/itdept/dete/messaging-2.0.0.BETA1/bin]$ 15:58:16,092 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Stopping JBoss Messaging Server 
> 15:58:16,924 WARNING [org.jboss.kernel.plugins.dependency.StartStopLifecycleAction]  Error during stop for JMSServerManager 
> java.lang.NullPointerException
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.stop(MessagingServerImpl.java:309)
> 	at org.jboss.messaging.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:172)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
> 	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
> 	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBean(AbstractKernelDeployer.java:394)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeployBeans(AbstractKernelDeployer.java:373)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.undeploy(AbstractKernelDeployer.java:162)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.undeploy(JBMBootstrapServer.java:177)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer.shutDown(JBMBootstrapServer.java:256)
> 	at org.jboss.messaging.integration.bootstrap.JBMBootstrapServer$1.run(JBMBootstrapServer.java:105)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)
> Restart Backup-->
> 15:58:32,350 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 15:58:34,221 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  Backup server will await live server before becoming operational 
> 15:58:34,273 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  JBoss Messaging Server version 2.0.0.BETA1 (tadpole, 102) started 
> Restart Live-->
> 12:57:25,709 INFO [org.jboss.messaging.integration.bootstrap.JBMBootstrapServer]  Starting JBoss Messaging Server 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:28,612 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> Backup sees Live-->
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO journal selected 
> 12:57:30,286 INFO [org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager]  AIO loaded successfully 
> 12:57:31,646 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler]  Failed to initialise 
> java.lang.IllegalStateException: Live and backup unique ids different. You're probably trying to restart a live backup pair after a crash
> 	at org.jboss.messaging.core.server.impl.MessagingServerImpl.initialiseBackup(MessagingServerImpl.java:611)
> 	at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:99)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
> 	at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
> 	at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:556)
> 	at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> 	at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
> 	at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 01:06:56 2009
From: jira-events at lists.jboss.org (Calvin Lin (JIRA))
Date: Thu, 18 Jun 2009 01:06:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7037) JBossAS 5.x fails to
 use EJB's
 security domain in jboss.xml when the call is from web container
In-Reply-To: <2821553.1245299576703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15952010.1245301616545.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Calvin Lin updated JBAS-7037:
-----------------------------

    Attachment: JBAS-jira-authenBug.zip


The zip file contains the web and ejb project that demonstrate the problem.
Please read readme.txt first.
The project uses JBossAS 5.1.0.GA.

> JBossAS 5.x fails to use EJB's security domain in jboss.xml when the call is from web container
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7037
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: Problem found on Windows platform
>            Reporter: Calvin Lin
>            Assignee: Anil Saldhana
>            Priority: Critical
>         Attachments: JBAS-jira-authenBug.zip
>
>
> A degredation from JBoss 4.0.x and 4.2.x to JBoss 5.0.1.GA and JBoss 5.1.0.GA.
> We noticed that the JAAS login in EJB container always picks up the Web app's security domain when the client login is originated from a web application client.  The security domain specified in EJB container's jboss.xml is always ignored in this situation.
> The detailed problem description is posted on JBoss forum:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156863

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 01:32:23 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 18 Jun 2009 01:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19784927.1245303143196.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472633#action_12472633 ] 

Tim Fox commented on JBMESSAGING-1658:
--------------------------------------

As of this morning, the servers have been sitting idle for over 12 hours with no errors

[tfox at messaging-01 logs]$ date
Thu Jun 18 01:30:01 EDT 2009


> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 01:36:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 18 Jun 2009 01:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2418205.1245303416601.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472635#action_12472635 ] 

Tim Fox commented on JBMESSAGING-1658:
--------------------------------------

Scott- if you could give me _exact_ instructions for replicating this it would help a lot, i.e. exact list of command lines etc, since I may be doing something different from you.

Basically I just started two nodes, live and backup on the same network using your config. The only difference I can see is I am not using virtualization.

Are you absolutely sure no one else is using the same network as you (you might get UDP interference from other servers).

> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 01:38:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 18 Jun 2009 01:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-207)
 NullPointerException during
 deployment of EJB3 methods with zero parameters
In-Reply-To: <31747213.1244728808387.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17985649.1245303536792.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472636#action_12472636 ] 

Andrew Lee Rubinger commented on JBMETA-207:
--------------------------------------------

Note: The test for JBMETA-152 uses SecureService.someMethod, which accepts no method parameters.  Why does this not result in NPE?

Zachary, could you attach the relevant sources for the deployable leading to this?  The fix is easy enough, but should be verified with a failing test that gets corrected.

> NullPointerException during deployment of EJB3 methods with zero parameters
> ---------------------------------------------------------------------------
>
>                 Key: JBMETA-207
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-207
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.0.GA
>         Environment: JBoss-5.1.0-GA, JDK 1.6.0_07-b06-153 (Apple/Sun JVM, 64-bit on OS/X), EJB3 w/ descriptor overrides
>            Reporter: Zachary Bedell
>            Assignee: Andrew Lee Rubinger
>         Attachments: fixJBMETA207.patch
>
>
> Deploying an EJB3 based EAR results in an NPE with the below stack trace.  The problem appears to manifest with EJB3's containing methods that take zero arguments.  There are also XML descriptor based attributes for several of the metadata elements.  To the best of my knowledge the descriptors only augment, not override anything specified in annotations.
> Patch for this should be trivial (an additional null check on line 83 of RolesAllowedProcessor.java should do it).  I'm in the process of attempting to get JBMETA built from source and integrated into my stack.  Will attach patch & tests unless someone beats me to it.
> The stack:
> 09:44:51,219 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=vfszip:/jboss/jboss-eap-5.0/server/ucmsfc/deploy/ucms.ear/ state=ClassLoader mode=Manual requiredState=PostClassLoader
> org.jboss.deployers.spi.DeploymentException: Cannot process metadata
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:181)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:93)
> 	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.install(DeployersImpl.java:1098)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:698)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:59)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:355)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
> 	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:310)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:241)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 	at org.jboss.Main.boot(Main.java:216)
> 	at org.jboss.Main$1.run(Main.java:546)
> 	at java.lang.Thread.run(Thread.java:637)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:83)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor.process(RolesAllowedProcessor.java:48)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:215)
> 	at org.jboss.metadata.annotation.creator.AbstractProcessor.processClass(AbstractProcessor.java:172)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:151)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:94)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:52)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.process(AbstractCreator.java:154)
> 	at org.jboss.metadata.annotation.creator.AbstractCreator.processMetaData(AbstractCreator.java:87)
> 	at org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator.create(JBoss50Creator.java:109)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processJBossMetaData(OptAnnotationMetaDataDeployer.java:134)
> 	at org.jboss.deployment.OptAnnotationMetaDataDeployer.processMetaData(OptAnnotationMetaDataDeployer.java:84)
> 	at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:177)
> 	... 31 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 02:10:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 18 Jun 2009 02:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-211) eclipse env setup
Message-ID: <7526884.1245305456586.JavaMail.jira@cloud.prod.atl2.jboss.com>

eclipse env setup
-----------------

                 Key: JBMETA-211
                 URL: https://jira.jboss.org/jira/browse/JBMETA-211
             Project: JBoss Metadata
          Issue Type: Task
      Security Level: Public (Everyone can see)
         Environment: eclipse IDE
            Reporter: Jeff Zhang
            Assignee: Alexey Loubyansky
            Priority: Minor


in the new common diectory, the eclipse project name is "common" defined in .project file, that is easy to conflict with other name, I suggest it should be like "jboss-metadata-common"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 02:18:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 18 Jun 2009 02:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3211797.1245305936821.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472640#action_12472640 ] 

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

The namespace is what distinguishes EJB2 descriptor from EJB3. DTDs don't have a namespace. EJB2 and EJB1 schemas are based on DTDs, so when a descriptor w/o a namespace is found it assumed to be EJB2.x one.
This is also how the metadata classes are bound with JAXB/JBossXB annotations. EJB3 metadata classes (as any Java class in principle) are bound to a specific namespace, which is http://java.sun.com/xml/ns/javaee in case of EJB3.

Although, we could make it work w/o a namespace (by copying EjbJar30MetaData class, binding it to an empty namespace and adjusting metadata version resolution logic (which will be now done outside of XB's SchemaResolver impl, but by a deployer probably)), I am so far not in favor of supporting this.

If you are writing an XML based on an XSD it is a given to include the namespace from the XSD. So, I would fix the EJB3 docs instead.

PS: the forum link is not really about this issue.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 02:20:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 18 Jun 2009 02:20:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-211) eclipse env setup
In-Reply-To: <7526884.1245305456586.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3010807.1245306056737.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472641#action_12472641 ] 

Jeff Zhang commented on JBMETA-211:
-----------------------------------

add eclipse env files for rar, r90373

> eclipse env setup
> -----------------
>
>                 Key: JBMETA-211
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-211
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>         Environment: eclipse IDE
>            Reporter: Jeff Zhang
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> in the new common diectory, the eclipse project name is "common" defined in .project file, that is easy to conflict with other name, I suggest it should be like "jboss-metadata-common"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 03:01:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 18 Jun 2009 03:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-212) rar annotation
	processing
Message-ID: <2713687.1245308516586.JavaMail.jira@cloud.prod.atl2.jboss.com>

rar annotation processing
-------------------------

                 Key: JBMETA-212
                 URL: https://jira.jboss.org/jira/browse/JBMETA-212
             Project: JBoss Metadata
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 1.0.2.Beta1
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang


handle jca 1.6 annotation

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 03:17:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 18 Jun 2009 03:17:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7008) expose a
 ManagedObject for EJB3 Entity Beans
In-Reply-To: <23432922.1244649836603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7591476.1245309477428.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-7008.
---------------------------------------

    Resolution: Won't Fix


> expose a ManagedObject for EJB3 Entity Beans
> --------------------------------------------
>
>                 Key: JBAS-7008
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7008
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This would allow us to list the deployed EJB3 entities as Jopr Resources even when Hibernate statistics are not enabled in the AS instance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 03:26:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 18 Jun 2009 03:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-211) eclipse env setup
In-Reply-To: <7526884.1245305456586.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22619057.1245310016909.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472646#action_12472646 ] 

Alexey Loubyansky commented on JBMETA-211:
------------------------------------------

eclipse project info was generated by mvn eclipse:eclipse. Originally I used common, client, ejb, etc as artifactId. Then I changed it to metadata-common, metadata-client, metadata-ejb, etc. So, regeneration should fix it.

> eclipse env setup
> -----------------
>
>                 Key: JBMETA-211
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-211
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>         Environment: eclipse IDE
>            Reporter: Jeff Zhang
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> in the new common diectory, the eclipse project name is "common" defined in .project file, that is easy to conflict with other name, I suggest it should be like "jboss-metadata-common"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 03:34:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 18 Jun 2009 03:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-211) eclipse env setup
In-Reply-To: <7526884.1245305456586.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8918783.1245310496564.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472647#action_12472647 ] 

Alexey Loubyansky commented on JBMETA-211:
------------------------------------------

Fixed for common (metadata-common) and ejb (metadata-ejb).

> eclipse env setup
> -----------------
>
>                 Key: JBMETA-211
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-211
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>         Environment: eclipse IDE
>            Reporter: Jeff Zhang
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> in the new common diectory, the eclipse project name is "common" defined in .project file, that is easy to conflict with other name, I suggest it should be like "jboss-metadata-common"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 03:38:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 18 Jun 2009 03:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-211) eclipse env setup
In-Reply-To: <7526884.1245305456586.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5904890.1245310736595.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472649#action_12472649 ] 

Jeff Zhang commented on JBMETA-211:
-----------------------------------

thanks Alex.
I use "jboss-metadata-rar" for rar part, I will change it to match your naming after next code submit.

> eclipse env setup
> -----------------
>
>                 Key: JBMETA-211
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-211
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>         Environment: eclipse IDE
>            Reporter: Jeff Zhang
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> in the new common diectory, the eclipse project name is "common" defined in .project file, that is easy to conflict with other name, I suggest it should be like "jboss-metadata-common"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 03:40:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 18 Jun 2009 03:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-211) eclipse env setup
In-Reply-To: <7526884.1245305456586.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25827950.1245310856542.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472650#action_12472650 ] 

Alexey Loubyansky commented on JBMETA-211:
------------------------------------------

I guess eclipse project name is not a big deal. You can use whatever you want. What we all have to agree on is a common artifactId format.

> eclipse env setup
> -----------------
>
>                 Key: JBMETA-211
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-211
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>         Environment: eclipse IDE
>            Reporter: Jeff Zhang
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> in the new common diectory, the eclipse project name is "common" defined in .project file, that is easy to conflict with other name, I suggest it should be like "jboss-metadata-common"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 04:22:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 18 Jun 2009 04:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMETA-211) eclipse env setup
In-Reply-To: <7526884.1245305456586.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30238293.1245313376616.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang closed JBMETA-211.
-----------------------------

    Resolution: Done


> eclipse env setup
> -----------------
>
>                 Key: JBMETA-211
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-211
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>         Environment: eclipse IDE
>            Reporter: Jeff Zhang
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> in the new common diectory, the eclipse project name is "common" defined in .project file, that is easy to conflict with other name, I suggest it should be like "jboss-metadata-common"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:01:07 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 18 Jun 2009 05:01:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1659) Create source
	distribution
Message-ID: <1154159.1245315667976.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create source distribution
--------------------------

                 Key: JBMESSAGING-1659
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1659
             Project: JBoss Messaging
          Issue Type: Task
          Components: Build System
    Affects Versions: 2.0.0 Beta1
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 2.0.0


JBoss Messaging build systems creates only binary distributions.
We must also create source distributions which contains the source.

An alternative is to always include the source in the distributions (the src dir is 4,4M and 1M when zipped)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:01:08 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 18 Jun 2009 05:01:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1659) Create source
	distribution
In-Reply-To: <1154159.1245315667976.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28342948.1245315668222.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated JBMESSAGING-1659:
-------------------------------------

    Affects Version/s: 2.0.0.beta2
                           (was: 2.0.0 Beta1)


> Create source distribution
> --------------------------
>
>                 Key: JBMESSAGING-1659
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1659
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>    Affects Versions: 2.0.0.beta2
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> JBoss Messaging build systems creates only binary distributions.
> We must also create source distributions which contains the source.
> An alternative is to always include the source in the distributions (the src dir is 4,4M and 1M when zipped)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:10:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMDR-58) Update to
 jboss-common-core 2.2.14.GA
Message-ID: <5995551.1245316256601.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update to jboss-common-core 2.2.14.GA
-------------------------------------

                 Key: JBMDR-58
                 URL: https://jira.jboss.org/jira/browse/JBMDR-58
             Project: JBoss MetaData Repository
          Issue Type: Thirdparty Change
          Components: Release
    Affects Versions: JBossMDR-2.0.1.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBossMDR-2.0.2.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:12:58 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:12:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMDR-59) Release JBoss MDR
	2.0.2.GA
Message-ID: <31196864.1245316378255.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release JBoss MDR 2.0.2.GA
--------------------------

                 Key: JBMDR-59
                 URL: https://jira.jboss.org/jira/browse/JBMDR-59
             Project: JBoss MetaData Repository
          Issue Type: Release
          Components: Release
    Affects Versions: JBossMDR-2.0.1.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBossMDR-2.0.2.GA


Release notes:
 - https://jira.jboss.org/jira/secure/ReleaseNote.jspa?version=12312897&styleName=Text&projectId=12310561&Create=Create

MVN repo:
 - http://anonsvn.jboss.org/repos/repository.jboss.org/maven2/org/jboss/jboss-mdr/2.0.2.GA/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:12:59 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:12:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMDR-5) Test annotation
 overrides at the Thread level in the metadata repository
Message-ID: <13463366.1245316379499.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMDR-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin updated JBMDR-5:
----------------------------

    Fix Version/s: JBossMDR-2.2.0.Alpha1
                       (was: JBossMDR-2.0.2.GA)


> Test annotation overrides at the Thread level in the metadata repository
> ------------------------------------------------------------------------
>
>                 Key: JBMDR-5
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-5
>             Project: JBoss MetaData Repository
>          Issue Type: Sub-task
>          Components: Tests
>            Reporter: Adrian Brock
>             Fix For: JBossMDR-2.2.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:12:59 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:12:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMDR-4) Test metadata for all
	joinpoints
Message-ID: <15882055.1245316379871.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMDR-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin updated JBMDR-4:
----------------------------

    Fix Version/s: JBossMDR-2.2.0.Alpha1
                       (was: JBossMDR-2.0.2.GA)


> Test metadata for all joinpoints
> --------------------------------
>
>                 Key: JBMDR-4
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-4
>             Project: JBoss MetaData Repository
>          Issue Type: Sub-task
>          Components: Tests
>            Reporter: Adrian Brock
>             Fix For: JBossMDR-2.2.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:12:59 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:12:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMDR-6) Test annotation
 overrides at the Invocation level in the metadata repository
Message-ID: <23827748.1245316379231.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMDR-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin updated JBMDR-6:
----------------------------

    Fix Version/s: JBossMDR-2.2.0.Alpha1
                       (was: JBossMDR-2.0.2.GA)


> Test annotation overrides at the Invocation level in the metadata repository
> ----------------------------------------------------------------------------
>
>                 Key: JBMDR-6
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-6
>             Project: JBoss MetaData Repository
>          Issue Type: Sub-task
>          Components: Tests
>            Reporter: Adrian Brock
>             Fix For: JBossMDR-2.2.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:12:58 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:12:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMDR-59) Release JBoss MDR
	2.0.2.GA
In-Reply-To: <31196864.1245316378255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13371423.1245316378483.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMDR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBMDR-59.
------------------------------

    Resolution: Done


> Release JBoss MDR 2.0.2.GA
> --------------------------
>
>                 Key: JBMDR-59
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-59
>             Project: JBoss MetaData Repository
>          Issue Type: Release
>          Components: Release
>    Affects Versions: JBossMDR-2.0.1.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBossMDR-2.0.2.GA
>
>
> Release notes:
>  - https://jira.jboss.org/jira/secure/ReleaseNote.jspa?version=12312897&styleName=Text&projectId=12310561&Create=Create
> MVN repo:
>  - http://anonsvn.jboss.org/repos/repository.jboss.org/maven2/org/jboss/jboss-mdr/2.0.2.GA/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:17:57 2009
From: jira-events at lists.jboss.org (Jbm User (JIRA))
Date: Thu, 18 Jun 2009 05:17:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1660) journal files
 not getting cleaned up and server startup fails
Message-ID: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>

journal files not getting cleaned up and server startup fails
-------------------------------------------------------------

                 Key: JBMESSAGING-1660
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core Persistence
    Affects Versions: 2.0.0 Beta1
         Environment: Windows Vista SP1 32 bit, 2 GB RAM
            Reporter: Jbm User
            Assignee: Tim Fox


Hi,
I am using JBM 2.0.0.BETA1 stand alone server.
I have added 1 million messages in a queue with following page settings in jbm-configuration.xml

<paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
<global-page-size>10485760</global-page-size>

When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
Now, I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:19:56 2009
From: jira-events at lists.jboss.org (Jbm User (JIRA))
Date: Thu, 18 Jun 2009 05:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1660) journal files
 not getting cleaned up and server startup fails
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17912237.1245316796731.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jbm User updated JBMESSAGING-1660:
----------------------------------

    Description: 
Hi,
I am using JBM 2.0.0.BETA1 stand alone server.
I have added 1 million messages in a queue with following page settings in jbm-configuration.xml

<paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
<global-page-size>10485760</global-page-size>

When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

  was:
Hi,
I am using JBM 2.0.0.BETA1 stand alone server.
I have added 1 million messages in a queue with following page settings in jbm-configuration.xml

<paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
<global-page-size>10485760</global-page-size>

When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
Now, I am not sure why server is loading the journal files on start up when all the messages are already consumed. 



> journal files not getting cleaned up and server startup fails
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Tim Fox
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:36:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-104) Update 3rd party libs
 for JBCL 2.0.7.GA
Message-ID: <3825526.1245317816612.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update 3rd party libs for JBCL 2.0.7.GA
---------------------------------------

                 Key: JBCL-104
                 URL: https://jira.jboss.org/jira/browse/JBCL-104
             Project: JBoss ClassLoader
          Issue Type: Thirdparty Change
          Components: Release
    Affects Versions: JBossCL.2.0.6.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBossCL.2.0.7.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:38:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-105) Update
 classloading-spi to 5.1.0.SP1
Message-ID: <28998810.1245317936717.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update classloading-spi to 5.1.0.SP1
------------------------------------

                 Key: JBCL-105
                 URL: https://jira.jboss.org/jira/browse/JBCL-105
             Project: JBoss ClassLoader
          Issue Type: Component Upgrade
          Components: Dependencies
    Affects Versions: JBossCL.2.0.6.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBossCL.2.0.7.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:40:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-106) Update to
 jboss-common-core 2.2.14.GA
Message-ID: <10304120.1245318056456.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update to jboss-common-core 2.2.14.GA
-------------------------------------

                 Key: JBCL-106
                 URL: https://jira.jboss.org/jira/browse/JBCL-106
             Project: JBoss ClassLoader
          Issue Type: Component Upgrade
          Components: Dependencies
    Affects Versions: JBossCL.2.0.6.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBossCL.2.0.7.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:45:07 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:45:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-105) Update
 classloading-spi to 5.1.0.SP1
In-Reply-To: <28998810.1245317936717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32033064.1245318307913.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBCL-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBCL-105.
------------------------------

    Resolution: Done


> Update classloading-spi to 5.1.0.SP1
> ------------------------------------
>
>                 Key: JBCL-105
>                 URL: https://jira.jboss.org/jira/browse/JBCL-105
>             Project: JBoss ClassLoader
>          Issue Type: Component Upgrade
>          Components: Dependencies
>    Affects Versions: JBossCL.2.0.6.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBossCL.2.0.7.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:04:57 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 06:04:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19634424.1245319497020.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBWEB-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472690#action_12472690 ] 

Mike Millson commented on JBWEB-142:
------------------------------------

Test Case:
1) Take heap with default configuration. Inspect org.apache.jasper.Constants and verify that DEFAULT_TAG_BUFFER_SIZE is 512. See attached default.png.
2) Add the following JVM option to run.conf:
 -Dorg.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE=1001
3) Take heap with default configuration. Inspect org.apache.jasper.Constants and verify that DEFAULT_TAG_BUFFER_SIZE is 1001. See attached set-to-1001.png.

> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: jbweb-142.patch
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:07:07 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 06:07:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14181711.1245319627818.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-142:
-------------------------------

    Attachment: default.png


Screen shot from Eclipse Memory Analyzer Tool showing default org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE of 512.

> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: default.png, jbweb-142.patch, set-to-1001.png
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:07:08 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 06:07:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Modifiable
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7241427.1245319628114.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-142:
-------------------------------

    Attachment: set-to-1001.png


Screen shot from Eclipse Memory Analyzer Tool showing org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE set to 1001 when -Dorg.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE=1001 JVM option used.

> Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> --------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: default.png, jbweb-142.patch, set-to-1001.png
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:10:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 18 Jun 2009 06:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1660) journal
 files not getting cleaned up and server startup fails
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26653240.1245319856642.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472695#action_12472695 ] 

Tim Fox commented on JBMESSAGING-1660:
--------------------------------------

Hello jbm user-

Can you please attach some simple client code which we can run to replicate this problem, along with exact instructions for replication?

Thanks.

> journal files not getting cleaned up and server startup fails
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Tim Fox
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:29:08 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 06:29:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-142) Parameterize
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21274052.1245320948445.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-142:
-------------------------------

    Summary: Parameterize org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE  (was: Modifiable org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE)


> Parameterize org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> ----------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Remy Maucherat
>         Attachments: default.png, jbweb-142.patch, set-to-1001.png
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:30:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 06:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBWEB-142) Parameterize
 org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
In-Reply-To: <22236590.1244686676536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27995159.1245321056912.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson reassigned JBWEB-142:
----------------------------------

    Assignee: Jean-Frederic Clere  (was: Remy Maucherat)


Since Remy is on vacation, can you please apply this upstream?

> Parameterize org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE
> ----------------------------------------------------------------
>
>                 Key: JBWEB-142
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-142
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP10
>            Reporter: Mike Millson
>            Assignee: Jean-Frederic Clere
>         Attachments: default.png, jbweb-142.patch, set-to-1001.png
>
>
> Add functionality to parameterize the buffer size of org.apache.jasper.runtime.BodyContentImpl.java (e.g. with an environment variable).
> Currently the buffer size is determined by the org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE constant, which is set 512 bytes, and there is no way to override this.
> Applications with many JSP pages that are larger than 512 bytes would benefit from a larger buffer size by avoiding excessive GC due to creating and destroying char arrays.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:35:56 2009
From: jira-events at lists.jboss.org (cristina gonzalez (JIRA))
Date: Thu, 18 Jun 2009 06:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1900) Task
 parent/child relationships support
In-Reply-To: <16282486.1229686014288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21429805.1245321356677.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472702#action_12472702 ] 

cristina gonzalez commented on JBRULES-1900:
--------------------------------------------

Hi Mauricio, I find what you posted really useful for what i am doing at the moment, but i am trying to get the files you uploaded and keeps saying they dont exist anymore, could you please upload them again so i can have a look at them please?

Thanks

Chrissie

> Task parent/child relationships support
> ---------------------------------------
>
>                 Key: JBRULES-1900
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1900
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (flow)
>    Affects Versions: 5.0.0.M1,  5.0.0.M2, 5.0.0.M3
>            Reporter: Mauricio Salatino
>            Assignee: Mauricio Salatino
>         Attachments: drools-process.rar, ParentChildRelationships.rar
>
>
> Support  for nested task inside a task in a ruleflow process. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 06:54:56 2009
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 18 Jun 2009 06:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-255)
 IdentityLoginModule
 Incomplete password-stacking useFirstPass implementation
In-Reply-To: <4221409.1214820452243.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21182225.1245322496580.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/SECURITY-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472705#action_12472705 ] 

Darran Lofthouse commented on SECURITY-255:
-------------------------------------------

The following class is a modification I needed to use to get this to work: -

 https://svn.jboss.org/repos/jbossas/projects/security/security-negotiation/branches/SECURITY-141/jboss-negotiation-extras/src/main/java/org/jboss/security/negotiation/spnego/IdentityLoginModule.java


> IdentityLoginModule Incomplete password-stacking useFirstPass implementation
> ----------------------------------------------------------------------------
>
>                 Key: SECURITY-255
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-255
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.2.CR6
>            Reporter: Darran Lofthouse
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.4
>
>
> The IdentityLoginModule has got an incomplete useFirstPass implementation.
> The login() method does start with: -
>   if( super.login() == true )
>          return true;
> To skip login if useFirstPass is set and authentication has already occurred.
> However at the end of login() setting the principal in the shared state map should only happen if useFirstPass was set.  
> Also for this to work a credential also needs to be stored in the sharedStateMap otherwise other modules will assume authentication has not occurred.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:09:01 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-194) Update 3rd party
 libs for Deployers 2.0.8.GA
Message-ID: <25398580.1245323341009.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update 3rd party libs for Deployers 2.0.8.GA
--------------------------------------------

                 Key: JBDEPLOY-194
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-194
             Project: JBoss Deployers
          Issue Type: Thirdparty Change
          Components: release
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:13:07 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:13:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-195) Release JBoss
 Deployers 2.0.8.GA
Message-ID: <3551125.1245323587737.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release JBoss Deployers 2.0.8.GA
--------------------------------

                 Key: JBDEPLOY-195
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-195
             Project: JBoss Deployers
          Issue Type: Release
          Components: release
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA


Release notes:
 - https://jira.jboss.org/jira/secure/ReleaseNote.jspa?version=12313669&styleName=Text&projectId=12310581&Create=Create

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:14:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-196) Update JBoss Man
	to 2.1.1.CR1
Message-ID: <6724157.1245323696453.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update JBoss Man to 2.1.1.CR1
-----------------------------

                 Key: JBDEPLOY-196
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-196
             Project: JBoss Deployers
          Issue Type: Component Upgrade
          Components: release
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:16:57 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-198) Update JBoss
 Kernel to 2.0.7.GA
Message-ID: <25985562.1245323817213.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update JBoss Kernel to 2.0.7.GA
-------------------------------

                 Key: JBDEPLOY-198
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-198
             Project: JBoss Deployers
          Issue Type: Component Upgrade
          Components: release
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:16:58 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:16:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-199) Update
 classloading-spi to 5.1.0.SP1
Message-ID: <9719728.1245323818486.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update classloading-spi to 5.1.0.SP1
------------------------------------

                 Key: JBDEPLOY-199
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-199
             Project: JBoss Deployers
          Issue Type: Component Upgrade
          Components: release
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:18:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-200) Update to
 jboss-common-core 2.2.14.GA
Message-ID: <14716024.1245323936498.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update to jboss-common-core 2.2.14.GA
-------------------------------------

                 Key: JBDEPLOY-200
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-200
             Project: JBoss Deployers
          Issue Type: Component Upgrade
          Components: release
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:22:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-107) Update JBoss Man to
	2.1.1.CR1
Message-ID: <19043462.1245324176682.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update JBoss Man to 2.1.1.CR1
-----------------------------

                 Key: JBCL-107
                 URL: https://jira.jboss.org/jira/browse/JBCL-107
             Project: JBoss ClassLoader
          Issue Type: Component Upgrade
          Components: Dependencies
    Affects Versions: JBossCL.2.0.6.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBossCL.2.0.7.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:22:58 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:22:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-108) Update JBoss Kernel
	to 2.0.7.GA
Message-ID: <7320847.1245324178625.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update JBoss Kernel to 2.0.7.GA
-------------------------------

                 Key: JBCL-108
                 URL: https://jira.jboss.org/jira/browse/JBCL-108
             Project: JBoss ClassLoader
          Issue Type: Component Upgrade
          Components: Dependencies
    Affects Versions: JBossCL.2.0.6.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBossCL.2.0.7.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:24:58 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:24:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-107) Update JBoss Man to
	2.1.1.CR1
In-Reply-To: <19043462.1245324176682.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27247324.1245324298642.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBCL-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBCL-107.
------------------------------

    Resolution: Done


> Update JBoss Man to 2.1.1.CR1
> -----------------------------
>
>                 Key: JBCL-107
>                 URL: https://jira.jboss.org/jira/browse/JBCL-107
>             Project: JBoss ClassLoader
>          Issue Type: Component Upgrade
>          Components: Dependencies
>    Affects Versions: JBossCL.2.0.6.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBossCL.2.0.7.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:36:56 2009
From: jira-events at lists.jboss.org (Mauricio Salatino (JIRA))
Date: Thu, 18 Jun 2009 07:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1900) Task
 parent/child relationships support
In-Reply-To: <16282486.1229686014288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23412413.1245325016568.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472719#action_12472719 ] 

Mauricio Salatino commented on JBRULES-1900:
--------------------------------------------

Hi Cristina,
This code is already on the trunk and in the final release of Drools 5.
Thanks

> Task parent/child relationships support
> ---------------------------------------
>
>                 Key: JBRULES-1900
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1900
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (flow)
>    Affects Versions: 5.0.0.M1,  5.0.0.M2, 5.0.0.M3
>            Reporter: Mauricio Salatino
>            Assignee: Mauricio Salatino
>         Attachments: drools-process.rar, ParentChildRelationships.rar
>
>
> Support  for nested task inside a task in a ruleflow process. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:02:57 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 08:02:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-199) Update
 classloading-spi to 5.1.0.SP1
In-Reply-To: <9719728.1245323818486.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15072337.1245326577502.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-199.
----------------------------------

    Resolution: Done


> Update classloading-spi to 5.1.0.SP1
> ------------------------------------
>
>                 Key: JBDEPLOY-199
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-199
>             Project: JBoss Deployers
>          Issue Type: Component Upgrade
>          Components: release
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:02:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 08:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-196) Update JBoss Man
	to 2.1.1.CR1
In-Reply-To: <6724157.1245323696453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25909901.1245326576718.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-196.
----------------------------------

    Resolution: Done


> Update JBoss Man to 2.1.1.CR1
> -----------------------------
>
>                 Key: JBDEPLOY-196
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-196
>             Project: JBoss Deployers
>          Issue Type: Component Upgrade
>          Components: release
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:02:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 08:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-197) Update JBoss MDR
	to 2.0.2.GA
In-Reply-To: <12941831.1245323696903.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29959472.1245326576880.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-197.
----------------------------------

    Resolution: Done


> Update JBoss MDR to 2.0.2.GA
> ----------------------------
>
>                 Key: JBDEPLOY-197
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-197
>             Project: JBoss Deployers
>          Issue Type: Component Upgrade
>          Components: release
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:02:57 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 08:02:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-200) Update to
 jboss-common-core 2.2.14.GA
In-Reply-To: <14716024.1245323936498.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22526332.1245326577716.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-200.
----------------------------------

    Resolution: Done


> Update to jboss-common-core 2.2.14.GA
> -------------------------------------
>
>                 Key: JBDEPLOY-200
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-200
>             Project: JBoss Deployers
>          Issue Type: Component Upgrade
>          Components: release
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:02:57 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 08:02:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-198) Update JBoss
 Kernel to 2.0.7.GA
In-Reply-To: <25985562.1245323817213.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15468785.1245326577067.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-198.
----------------------------------

    Resolution: Done


> Update JBoss Kernel to 2.0.7.GA
> -------------------------------
>
>                 Key: JBDEPLOY-198
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-198
>             Project: JBoss Deployers
>          Issue Type: Component Upgrade
>          Components: release
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:08:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 08:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-194) Update 3rd party
 libs for Deployers 2.0.8.GA
In-Reply-To: <25398580.1245323341009.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24406430.1245326936683.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-194.
----------------------------------

    Resolution: Done


> Update 3rd party libs for Deployers 2.0.8.GA
> --------------------------------------------
>
>                 Key: JBDEPLOY-194
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-194
>             Project: JBoss Deployers
>          Issue Type: Thirdparty Change
>          Components: release
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:10:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 08:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-195) Release JBoss
 Deployers 2.0.8.GA
In-Reply-To: <3551125.1245323587737.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11636934.1245327056935.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-195.
----------------------------------

    Resolution: Done


> Release JBoss Deployers 2.0.8.GA
> --------------------------------
>
>                 Key: JBDEPLOY-195
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-195
>             Project: JBoss Deployers
>          Issue Type: Release
>          Components: release
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>
> Release notes:
>  - https://jira.jboss.org/jira/secure/ReleaseNote.jspa?version=12313669&styleName=Text&projectId=12310581&Create=Create

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 09:02:00 2009
From: jira-events at lists.jboss.org (Jbm User (JIRA))
Date: Thu, 18 Jun 2009 09:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1660) journal files
 not getting cleaned up and server startup fails
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13004560.1245330120720.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jbm User updated JBMESSAGING-1660:
----------------------------------

    Attachment: src.zip
                jbm-configuration.xml
                jbm-jms.xml


Hi Tim,
Thank you for the prompt response. Attached is the client code I am using. I have had this issue a few times yesterday and this morning but unfortunately I am not able to reproduce the issue now. However, I am able to reproduce it when I perform following steps. Hope it helps

1) Start server (I am using the server instance provided in messaging-2.0.0.BETA1\bin). Config files are attached
2) Run JMSSender.java to send 1 million messages and let it complete
3) Run JMSConsumer.java and while it is running (say after consuming 100000 messages), terminate server
4) JMSConsumer will detect that the connection is closed and will exit in 1 minute
5) Start the server
6) Run JMSConsumer.java again.
7) Observe that the number of journal files keep on increasing while the messages are being consumed.
8) Let the JMSConsumer complete (exits automatically 1 minute after consuming all the messages)
9) Observe that the paging folder is empty (except for address.txt file) and journal folder still has number of files
10) Try to restart the server and observe that it fails with java.lang.OutOfMemoryError

Thank You

> journal files not getting cleaned up and server startup fails
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Tim Fox
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 09:05:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 18 Jun 2009 09:05:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1660) journal
 files not getting cleaned up and server startup fails
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28532481.1245330357621.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox reassigned JBMESSAGING-1660:
------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)


> journal files not getting cleaned up and server startup fails
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 09:36:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 09:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20055513.1245332216895.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson reassigned JBWEB-144:
----------------------------------

    Assignee: Jean-Frederic Clere  (was: Remy Maucherat)


> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Jean-Frederic Clere
>         Attachments: jbweb-144.patch, test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 09:52:58 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Thu, 18 Jun 2009 09:52:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15390224.1245333178552.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-6185:
---------------------------------

    Assignee: Jason T. Greene  (was: Dimitris Andreadis)
    Priority: Blocker  (was: Major)


> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Jason T. Greene
>            Priority: Blocker
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 09:56:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 09:56:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28285840.1245333417956.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472753#action_12472753 ] 

Clebert Suconic commented on JBMESSAGING-1658:
----------------------------------------------

>From this message:

13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f


And this message:

14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl] A connection has been made to the backup server so it will be activated! This



It seems there was a client failing into the backup?

> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 09:58:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 09:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24977076.1245333536981.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472754#action_12472754 ] 

Clebert Suconic commented on JBMESSAGING-1658:
----------------------------------------------

what I was asking was.. .maybe Scott also had clients on his scenario. Not just the server sitting alone?

> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:01:04 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Thu, 18 Jun 2009 10:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4591608.1245333664106.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472758#action_12472758 ] 

Charles Crouch commented on JBAS-6185:
--------------------------------------

There are customers who want to see jboss and jvm mbeans collocated in the same mbeanserver so that JON can monitor them, (jboss.platform.mbeanserver) but also want remote jmx enabled so they can connect directly to an instance with jconsole (com.sun.jmxremote.port=???). However enabling both of these at the same time no longer seems possible.

> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Jason T. Greene
>            Priority: Blocker
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:04:59 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 18 Jun 2009 10:04:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6943) jboss threads
 metadata missing propOrder
In-Reply-To: <11303033.1242746411360.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31420966.1245333899507.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated JBAS-6943:
------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1


> jboss threads metadata missing propOrder
> ----------------------------------------
>
>                 Key: JBAS-6943
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6943
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Alexey Loubyansky
>            Assignee: David Lloyd
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfsfile:/C:/Users/avoka/svn.jboss.org/jbossas/Branch_5_x/build/output/jboss-5.1.0.GA/server/default/deploy/xnio-provider.jar/
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:362)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:322)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:294)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.deploy(AbstractParsingDeployerWithOutput.java:234)
> 	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.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(Unknown Source)
> Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Property order is not specified for type org.jboss.threads.metadata.ThreadsMetaData bound to a sequence. Property order can be specified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: threadPoolExecutors threadFactories scheduledThreadPoolExecutors threadGroups notatingExecutors directExecutors
> at org.jboss.threads.metadata.ThreadsMetaData
> 	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)
> 	at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:168)
> 	at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:189)
> 	at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:166)
> 	at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:137)
> 	at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:121)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:239)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:355)
> 	... 33 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:04:58 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 18 Jun 2009 10:04:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1324080.1245333898255.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472761#action_12472761 ] 

Tim Fox commented on JBMESSAGING-1658:
--------------------------------------

Yes, clebert I think you are right.

You would only get this message:

14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl] A connection has been made to the backup server so it will be activated! This 

if a client program attempted to make a connection directly to the backup server or failed over from live to backup, so there must be more things going on here than just two idle servers.

> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:09:56 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 10:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4405797.1245334196711.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBWEB-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472765#action_12472765 ] 

Mike Millson commented on JBWEB-144:
------------------------------------

Solution decided is to rebase org.apache.el to 6.0.20.

> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Jean-Frederic Clere
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:11:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 18 Jun 2009 10:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7038) Track component
 update - 5.2.0.Beta1
Message-ID: <2791010.1245334316593.JavaMail.jira@cloud.prod.atl2.jboss.com>

Track component update - 5.2.0.Beta1
------------------------------------

                 Key: JBAS-7038
                 URL: https://jira.jboss.org/jira/browse/JBAS-7038
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Other
            Reporter: Jason T. Greene
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:15:59 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 18 Jun 2009 10:15:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24953999.1245334559268.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene reassigned JBAS-6185:
-------------------------------------

    Assignee: Shelly McGowan  (was: Jason T. Greene)


Shelly, could you take a look at this one?

> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Shelly McGowan
>            Priority: Blocker
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:58:58 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 18 Jun 2009 10:58:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7037) JBossAS 5.x fails to
 use EJB's
 security domain in jboss.xml when the call is from web container
In-Reply-To: <2821553.1245299576703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2609508.1245337138664.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBAS-7037:
--------------------------------

    Assignee: Stefan Guilhen  (was: Anil Saldhana)
    Priority: Major  (was: Critical)


Stefan,  take an initial look at this case in the next few days.

> JBossAS 5.x fails to use EJB's security domain in jboss.xml when the call is from web container
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7037
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: Problem found on Windows platform
>            Reporter: Calvin Lin
>            Assignee: Stefan Guilhen
>         Attachments: JBAS-jira-authenBug.zip
>
>
> A degredation from JBoss 4.0.x and 4.2.x to JBoss 5.0.1.GA and JBoss 5.1.0.GA.
> We noticed that the JAAS login in EJB container always picks up the Web app's security domain when the client login is originated from a web application client.  The security domain specified in EJB container's jboss.xml is always ignored in this situation.
> The detailed problem description is posted on JBoss forum:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156863

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 11:00:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 18 Jun 2009 11:00:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7037) JBossAS 5.x fails to
 use EJB's
 security domain in jboss.xml when the call is from web container
In-Reply-To: <2821553.1245299576703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24171479.1245337256646.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBAS-7037:
--------------------------------

    Fix Version/s: JBossAS-5.0.2.GA


Maybe a metadata merge issue.

> JBossAS 5.x fails to use EJB's security domain in jboss.xml when the call is from web container
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7037
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: Problem found on Windows platform
>            Reporter: Calvin Lin
>            Assignee: Stefan Guilhen
>             Fix For: JBossAS-5.0.2.GA
>
>         Attachments: JBAS-jira-authenBug.zip
>
>
> A degredation from JBoss 4.0.x and 4.2.x to JBoss 5.0.1.GA and JBoss 5.1.0.GA.
> We noticed that the JAAS login in EJB container always picks up the Web app's security domain when the client login is originated from a web application client.  The security domain specified in EJB container's jboss.xml is always ignored in this situation.
> The detailed problem description is posted on JBoss forum:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156863

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 11:11:58 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 18 Jun 2009 11:11:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1658) Live/Backup
 pair in a
 cluster get themselves into a bad state after being up for a few hours
In-Reply-To: <7616018.1245265316833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20706048.1245337918892.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-1658.
--------------------------------

    Resolution: Rejected


Closed on reporters request.

> Live/Backup pair in a cluster get themselves into a bad state after being up for a few hours
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1658
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1658
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>         Environment: Using the same env and config files attached in JBMESSAGING-1646, except using BETA2 distro.
>            Reporter: Scott Clasen
>            Assignee: Tim Fox
>         Attachments: threadDumps.txt
>
>
> Clocks on the 2 boxes are in sync so notice the times in the log entries below.
> PRIMARY
> 13:12:50,844 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,844 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 60b6035d-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl]  Connection failure has been detected Did not receive ping on connection. It is likely a client has exited or crashed without closing its connection, or the network between the server and client has failed. The connection will now be closed.:3
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Client connection failed, clearing up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 13:12:50,896 WARNING [org.jboss.messaging.core.server.impl.ServerSessionImpl]  Cleared up resources for session 61f5883e-5b61-11de-bdd6-00123f76879f
> 14:02:13,485 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,589 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:13,693 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...
> =======================================================================================================================================
> SECONDARY
> 14:02:15,939 INFO [org.jboss.messaging.core.server.impl.MessagingServerImpl]  A connection has been made to the backup server so it will be activated! This 
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,094 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> 14:02:16,147 WARNING [org.jboss.messaging.core.cluster.impl.DiscoveryGroupImpl]  There seem to be more than one broadcasters on the network broadcasting the same node id
> ...MESSAGE REPEATS TILL SERVER KILLED...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 11:23:57 2009
From: jira-events at lists.jboss.org (Joshua Davis (JIRA))
Date: Thu, 18 Jun 2009 11:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-56) Add tests that
 bootstraps are shutdown in reverse order from start
In-Reply-To: <30621135.1240858006745.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32689544.1245338637257.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Davis updated JBBOOT-56:
-------------------------------

    Attachment: JBBOOT-56.v1.patch


Here's my first attempt at a test for this.   Notes:
1) I put it in jboss-bootstrap-impl-mc.  Not sure which module was the right one.
2) There three urls in the bootstrap.  Each one defines one instance of a test POJO.
3) Extracted the code that gets a bean from the MC by name into a helper.   More code than I expected.
4) Found that the MC 'cleans up' properties that were set in the bean XML at shutdown.   Wow... That's squeaky clean.


> Add tests that bootstraps are shutdown in reverse order from start
> ------------------------------------------------------------------
>
>                 Key: JBBOOT-56
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-56
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-base
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: Unscheduled
>
>         Attachments: JBBOOT-56.v1.patch
>
>
> Ensure that we are shutting down in proper sequence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 11:26:07 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 18 Jun 2009 11:26:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7019) Fork the existing
 tomcat integration code from AS into Spider
In-Reply-To: <22128270.1245060656840.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7266944.1245338767418.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved JBAS-7019.
---------------------------------

    Resolution: Done


> Fork the existing tomcat integration code from AS into Spider
> -------------------------------------------------------------
>
>                 Key: JBAS-7019
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7019
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 11:59:10 2009
From: jira-events at lists.jboss.org (Jonathon Leibundguth (JIRA))
Date: Thu, 18 Jun 2009 11:59:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2125) Drools core
 multithreading issue
In-Reply-To: <26229278.1245145676528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26572824.1245340750182.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472806#action_12472806 ] 

Jonathon Leibundguth commented on JBRULES-2125:
-----------------------------------------------

Think I've found something similar, but wasn't sure whether to add as a new issue - I had believed it might be the same as 2114, possibly like this one, however, it may be unique.  I don't currently have a unit test for this, we would have too much code to upload to show it right now -- but detected deadlock was using jconsole between 3 threads:

thread 1, called "droolsFireUntilHalt" is attempting to expire an object/fact while running fireUntilHalt()

thread 2, called "pool-2-thread-1", is an internal drools thread and its running a timer (defined in a .rf file) that injects a fact every 2 seconds to kick off rules -- it blocks on that insert() on working memory

thread 3, called "jpCapSensorThread", is inserting objects into a stream / named entry point - it also blocks on insert(), this time on a named entry point.

Below are the traces from these threads:

Name: droolsFireUntilHalt
State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync at 1def658 owned by: jpCapSensorThread
Total blocked: 293  Total waited: 293

Stack trace: 
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
org.drools.common.NamedEntryPoint.retract(NamedEntryPoint.java:258)
org.drools.common.NamedEntryPoint.retract(NamedEntryPoint.java:245)
org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteExpireAction.execute(ReteooWorkingMemory.java:350)
org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1486)
   - locked java.util.LinkedList at e707bb
org.drools.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1067)
org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:701)
   - locked org.drools.reteoo.ReteooStatefulSession at 14fa79d
org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:678)
   - locked org.drools.reteoo.ReteooStatefulSession at 14fa79d
org.drools.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:195)

---------

Name: pool-2-thread-1
State: BLOCKED on java.util.LinkedList at e707bb owned by: droolsFireUntilHalt
Total blocked: 1  Total waited: 296

Stack trace: 
org.drools.common.AbstractWorkingMemory.queueWorkingMemoryAction(AbstractWorkingMemory.java:1509)
org.drools.reteoo.ObjectTypeNode$ExpireJob.execute(ObjectTypeNode.java:443)
org.drools.time.impl.JDKTimerService$JDKCallableJob.call(JDKTimerService.java:132)
org.drools.time.impl.JDKTimerService$JDKCallableJob.call(JDKTimerService.java:110)
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
java.util.concurrent.FutureTask.run(FutureTask.java:138)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:619)

--------

Name: jpCapSensorThread
State: BLOCKED on java.util.LinkedList at e707bb owned by: droolsFireUntilHalt
Total blocked: 4  Total waited: 0

Stack trace: 
org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1479)
org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:158)
org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:122)
org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:80)
org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:28)
com.raytheon.nsff.spi.jpcap.DNSPacketInjector.receivePacket(DNSPacketInjector.java:23)
jpcap.JpcapCaptor.loopPacket(Native Method)
com.raytheon.nsff.spi.jpcap.JPCapSPIImpl$1.run(JPCapSPIImpl.java:98)
java.lang.Thread.run(Thread.java:619)



> Drools core multithreading issue
> --------------------------------
>
>                 Key: JBRULES-2125
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2125
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: Java HotSpot v 1.6.0_06, WinXP SP3
>            Reporter: Andrey Nechaev
>            Assignee: Edson Tirelli
>         Attachments: Main.java
>
>
> Attachement below is the code showing the problems. 
> The program hangs and nothing is displayed in the Console.
> If I put lines 10-11 before the line 6, I get a NullPointerException:
> Exception in thread "main" java.lang.NullPointerException
>             at org.drools.reteoo.ObjectSource.addObjectSink(ObjectSource.java:124)
> ...
> But, if I comment out the lines 2&3, everything works ok.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 12:07:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 12:07:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1660) journal
 files not getting cleaned up and server startup fails
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5396639.1245341277550.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472813#action_12472813 ] 

Clebert Suconic commented on JBMESSAGING-1660:
----------------------------------------------

Thanks for the testcase.

I could replicate the issue, and I' m working on a fix now.

It looks like something related to reloading DuplicateIDCacheImpl. I' m investigating it now.

> journal files not getting cleaned up and server startup fails
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 12:38:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 18 Jun 2009 12:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-90)
 PropertiesCompositeObjectNameMetaMapper uses invalid domain
Message-ID: <17256746.1245343136516.JavaMail.jira@cloud.prod.atl2.jboss.com>

PropertiesCompositeObjectNameMetaMapper uses invalid domain
-----------------------------------------------------------

                 Key: JBMAN-90
                 URL: https://jira.jboss.org/jira/browse/JBMAN-90
             Project: JBoss Managed
          Issue Type: Bug
          Components: metatype
    Affects Versions: JBossMan.2.1.1.Beta3
            Reporter: Brian Stansberry


Problem is in last line below:

public ObjectName unwrapMetaValue(MetaValue metaValue)
   {
      CompositeValue compositeValue = (CompositeValue) metaValue;
      SimpleValue domain = (SimpleValue) compositeValue.get("domain");
      String domainUnwrap = domain.toString();

Results in:

javax.management.MalformedObjectNameException: Invalid domain: SimpleMetaType:java.lang.String:jgroups

Needs to be:

String domainUnwrap = (String) domain.getValue();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 12:48:56 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 18 Jun 2009 12:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6960) once a Topic or
 Queue has been
 stopped via the 'stop' operation, none of its operations or properties
 work, and thus it cannot be restarted using the 'start' operation
In-Reply-To: <11989891.1242832445240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32707279.1245343736754.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved JBAS-6960.
---------------------------------------

    Resolution: Done


> once a Topic or Queue has been stopped via the 'stop' operation, none of its operations or properties work, and thus it cannot be restarted using the 'start' operation
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6960
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6960
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Ian Springer
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:10:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMDR-58) Update to
 jboss-common-core 2.2.14.GA
In-Reply-To: <5995551.1245316256601.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3418765.1245316256796.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMDR-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBMDR-58.
------------------------------

    Resolution: Done


> Update to jboss-common-core 2.2.14.GA
> -------------------------------------
>
>                 Key: JBMDR-58
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-58
>             Project: JBoss MetaData Repository
>          Issue Type: Thirdparty Change
>          Components: Release
>    Affects Versions: JBossMDR-2.0.1.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBossMDR-2.0.2.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:12:58 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:12:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMDR-7) Test annotation
 overrides at
 deployment time don't pick up thread and invocation level
Message-ID: <28575849.1245316378868.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMDR-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin updated JBMDR-7:
----------------------------

    Fix Version/s: JBossMDR-2.2.0.Alpha1
                       (was: JBossMDR-2.0.2.GA)


> Test annotation overrides at deployment time don't pick up thread and invocation level
> --------------------------------------------------------------------------------------
>
>                 Key: JBMDR-7
>                 URL: https://jira.jboss.org/jira/browse/JBMDR-7
>             Project: JBoss MetaData Repository
>          Issue Type: Sub-task
>          Components: Tests
>            Reporter: Adrian Brock
>             Fix For: JBossMDR-2.2.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 05:45:07 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 05:45:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-106) Update to
 jboss-common-core 2.2.14.GA
In-Reply-To: <10304120.1245318056456.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5672415.1245318307622.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBCL-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBCL-106.
------------------------------

    Resolution: Done


> Update to jboss-common-core 2.2.14.GA
> -------------------------------------
>
>                 Key: JBCL-106
>                 URL: https://jira.jboss.org/jira/browse/JBCL-106
>             Project: JBoss ClassLoader
>          Issue Type: Component Upgrade
>          Components: Dependencies
>    Affects Versions: JBossCL.2.0.6.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBossCL.2.0.7.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 14:17:56 2009
From: jira-events at lists.jboss.org (John Gilbert (JIRA))
Date: Thu, 18 Jun 2009 14:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
Message-ID: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>

ejb-jar.xml <interceptor-order> not supported
---------------------------------------------

                 Key: EJBTHREE-1852
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
             Project: EJB 3.0
          Issue Type: Bug
          Components: deployers, ejb3, interceptors
    Affects Versions: 1.1.5
            Reporter: John Gilbert


The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.

Caused by: java.lang.NullPointerException
        at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
        at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
        at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
        at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
        at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
        at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
        at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)



   <assembly-descriptor>
      <interceptor-binding>
         <ejb-name>*</ejb-name>
            <interceptor-order>
         	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
         	<interceptor-class>my.CustomInterceptor</interceptor-class>
            </interceptor-order>
      </interceptor-binding>
   </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 13:38:09 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 18 Jun 2009 13:38:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2128) Change the
 drools.rulebaseUpdateHandler property to default to none
Message-ID: <33524274.1245346689053.JavaMail.jira@cloud.prod.atl2.jboss.com>

Change the drools.rulebaseUpdateHandler property to default to none
-------------------------------------------------------------------

                 Key: JBRULES-2128
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2128
             Project: JBoss Drools
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: drools-api, drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


Change the drools.rulebaseUpdateHandler property to default to none

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 13:47:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 18 Jun 2009 13:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMAN-90)
 PropertiesCompositeObjectNameMetaMapper uses invalid domain
In-Reply-To: <17256746.1245343136516.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9676497.1245347276517.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMAN-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBMAN-90.
---------------------------------

    Fix Version/s: JBossMan.2.1.1.CR1
       Resolution: Done


> PropertiesCompositeObjectNameMetaMapper uses invalid domain
> -----------------------------------------------------------
>
>                 Key: JBMAN-90
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-90
>             Project: JBoss Managed
>          Issue Type: Bug
>          Components: metatype
>    Affects Versions: JBossMan.2.1.1.Beta3
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossMan.2.1.1.CR1
>
>
> Problem is in last line below:
> public ObjectName unwrapMetaValue(MetaValue metaValue)
>    {
>       CompositeValue compositeValue = (CompositeValue) metaValue;
>       SimpleValue domain = (SimpleValue) compositeValue.get("domain");
>       String domainUnwrap = domain.toString();
> Results in:
> javax.management.MalformedObjectNameException: Invalid domain: SimpleMetaType:java.lang.String:jgroups
> Needs to be:
> String domainUnwrap = (String) domain.getValue();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 14:45:37 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Thu, 18 Jun 2009 14:45:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7039) Allow IBM
 PKCS11IMPLKS to be used with JaasSecurityDomain
In-Reply-To: <14671838.1245350048812.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9449547.1245350737130.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcus Moyses resolved JBAS-7039.
---------------------------------

    Resolution: Done


Modified code to work with IBM's implementation as well.

> Allow IBM PKCS11IMPLKS to be used with JaasSecurityDomain
> ---------------------------------------------------------
>
>                 Key: JBAS-7039
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7039
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Must add a feature to work with both PKCS11 and PKCS11IMPLKS keystore types in JaasSecurityDomain.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 14:45:36 2009
From: jira-events at lists.jboss.org (John Gilbert (JIRA))
Date: Thu, 18 Jun 2009 14:45:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11500264.1245350736909.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472844#action_12472844 ] 

John Gilbert commented on EJBTHREE-1852:
----------------------------------------

this works fine in AS 4.2.3, but not when I switch to AS 5.1.

> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: deployers, ejb3, interceptors
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 13:38:08 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 18 Jun 2009 13:38:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMAN-90)
 PropertiesCompositeObjectNameMetaMapper uses invalid domain
In-Reply-To: <17256746.1245343136516.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30767253.1245346688730.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMAN-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned JBMAN-90:
-------------------------------------

    Assignee: Brian Stansberry


> PropertiesCompositeObjectNameMetaMapper uses invalid domain
> -----------------------------------------------------------
>
>                 Key: JBMAN-90
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-90
>             Project: JBoss Managed
>          Issue Type: Bug
>          Components: metatype
>    Affects Versions: JBossMan.2.1.1.Beta3
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> Problem is in last line below:
> public ObjectName unwrapMetaValue(MetaValue metaValue)
>    {
>       CompositeValue compositeValue = (CompositeValue) metaValue;
>       SimpleValue domain = (SimpleValue) compositeValue.get("domain");
>       String domainUnwrap = domain.toString();
> Results in:
> javax.management.MalformedObjectNameException: Invalid domain: SimpleMetaType:java.lang.String:jgroups
> Needs to be:
> String domainUnwrap = (String) domain.getValue();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 16:13:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 16:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1660)
 DuplicateIDCacheImpl won't delete records after reload
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30086943.1245356036815.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1660:
-----------------------------------------

        Fix Version/s: 2.0.0
    Affects Version/s: 2.0.0.beta2


> DuplicateIDCacheImpl won't delete records after reload
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 15:56:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 15:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1660)
 DuplicateIDCacheImpl won't delete records after reload
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <466852.1245355016948.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1660:
-----------------------------------------

    Summary: DuplicateIDCacheImpl won't delete records after reload  (was: journal files not getting cleaned up and server startup fails)


I have replicated the issue.

DuplicateCacheImpl position is out of sync after reload. 

It should be fixed soon.

> DuplicateIDCacheImpl won't delete records after reload
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 16:13:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 16:13:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1660)
 DuplicateIDCacheImpl won't delete records after reload
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12972943.1245356037190.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1660.
----------------------------------------

    Resolution: Done


Thanks for the report.

It's fixed on trunk now

> DuplicateIDCacheImpl won't delete records after reload
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:08:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-190) Fix
	TreeStructureCache
In-Reply-To: <5441871.1244481116496.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14860229.1245323337449.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-190.
----------------------------------

    Resolution: Done


> Fix TreeStructureCache
> ----------------------
>
>                 Key: JBDEPLOY-190
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-190
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: structure
>    Affects Versions: JBDEPLOY-2.0.7.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.0.8.GA
>
>
> TreeStructureCache shows strange leaves in MC demos.
> e.g. node's names do not equal to node's children; empty names vs. 2 children

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:14:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-197) Update JBoss MDR
	to 2.0.2.GA
Message-ID: <12941831.1245323696903.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update JBoss MDR to 2.0.2.GA
----------------------------

                 Key: JBDEPLOY-197
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-197
             Project: JBoss Deployers
          Issue Type: Component Upgrade
          Components: release
    Affects Versions: JBDEPLOY-2.0.7.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.0.8.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 07:24:58 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 18 Jun 2009 07:24:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-108) Update JBoss Kernel
	to 2.0.7.GA
In-Reply-To: <7320847.1245324178625.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28974789.1245324298445.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBCL-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBCL-108.
------------------------------

    Resolution: Done


> Update JBoss Kernel to 2.0.7.GA
> -------------------------------
>
>                 Key: JBCL-108
>                 URL: https://jira.jboss.org/jira/browse/JBCL-108
>             Project: JBoss ClassLoader
>          Issue Type: Component Upgrade
>          Components: Dependencies
>    Affects Versions: JBossCL.2.0.6.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBossCL.2.0.7.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 13:44:05 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 18 Jun 2009 13:44:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2128) Change the
 drools.rulebaseUpdateHandler property to default to none
In-Reply-To: <33524274.1245346689053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20865340.1245347045980.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2128.
----------------------------------

    Resolution: Done


Done.

> Change the drools.rulebaseUpdateHandler property to default to none
> -------------------------------------------------------------------
>
>                 Key: JBRULES-2128
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2128
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-api, drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> Change the drools.rulebaseUpdateHandler property to default to none

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 14:34:08 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Thu, 18 Jun 2009 14:34:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7039) Allow IBM
 PKCS11IMPLKS to be used with JaasSecurityDomain
Message-ID: <14671838.1245350048812.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow IBM PKCS11IMPLKS to be used with JaasSecurityDomain
---------------------------------------------------------

                 Key: JBAS-7039
                 URL: https://jira.jboss.org/jira/browse/JBAS-7039
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Marcus Moyses
            Assignee: Marcus Moyses
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


Must add a feature to work with both PKCS11 and PKCS11IMPLKS keystore types in JaasSecurityDomain.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 08:33:56 2009
From: jira-events at lists.jboss.org (cristina gonzalez (JIRA))
Date: Thu, 18 Jun 2009 08:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1900) Task
 parent/child relationships support
In-Reply-To: <16282486.1229686014288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28823282.1245328436659.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472735#action_12472735 ] 

cristina gonzalez commented on JBRULES-1900:
--------------------------------------------

Ohh thanks Mauricio.

> Task parent/child relationships support
> ---------------------------------------
>
>                 Key: JBRULES-1900
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1900
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (flow)
>    Affects Versions: 5.0.0.M1,  5.0.0.M2, 5.0.0.M3
>            Reporter: Mauricio Salatino
>            Assignee: Mauricio Salatino
>         Attachments: drools-process.rar, ParentChildRelationships.rar
>
>
> Support  for nested task inside a task in a ruleflow process. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 09:07:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 18 Jun 2009 09:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-255)
 IdentityLoginModule Incomplete
 password-stacking useFirstPass implementation
In-Reply-To: <4221409.1214820452243.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24610936.1245330476453.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated SECURITY-255:
-----------------------------------

      Component/s: Negotiation
                       (was: JBossSX)
    Fix Version/s: Negotiation_2.0.4.GA
                       (was: JBossSecurity_2.0.4)
         Assignee: Darran Lofthouse  (was: Anil Saldhana)


> IdentityLoginModule Incomplete password-stacking useFirstPass implementation
> ----------------------------------------------------------------------------
>
>                 Key: SECURITY-255
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-255
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: 2.0.2.CR6
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2.0.4.GA
>
>
> The IdentityLoginModule has got an incomplete useFirstPass implementation.
> The login() method does start with: -
>   if( super.login() == true )
>          return true;
> To skip login if useFirstPass is set and authentication has already occurred.
> However at the end of login() setting the principal in the shared state map should only happen if useFirstPass was set.  
> Also for this to work a credential also needs to be stored in the sharedStateMap otherwise other modules will assume authentication has not occurred.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 10:07:57 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 18 Jun 2009 10:07:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-144) JSP EL ternary
 operator requires space before colon
In-Reply-To: <6312683.1244740316628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9490112.1245334077059.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBWEB-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBWEB-144:
-------------------------------

    Attachment:     (was: jbweb-144.patch)


> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
>                 Key: JBWEB-144
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-144
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-2.0.0.GA_CP09
>            Reporter: Mike Millson
>            Assignee: Jean-Frederic Clere
>         Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
>        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 14:38:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 18 Jun 2009 14:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <11919252.1245350336801.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBAS-7032:
------------------------------------

    Assignee: Shelly McGowan  (was: Scott Marlow)


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 17:08:57 2009
From: jira-events at lists.jboss.org (Peter Crossley (JIRA))
Date: Thu, 18 Jun 2009 17:08:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1661) Messages in
 JBoss 5.1 that
 use bridging get stuck in a devlivering mode and are not sent to the remote
 cluster
Message-ID: <29236051.1245359337536.JavaMail.jira@cloud.prod.atl2.jboss.com>

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://jira.jboss.org/jira/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: Tim Fox
             Fix For: 1.4.4.GA


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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 17:46:58 2009
From: jira-events at lists.jboss.org (Jim Brownfield (JIRA))
Date: Thu, 18 Jun 2009 17:46:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6499)
 jboss.tomcat.connectors.started JMX Notification Missing
In-Reply-To: <12599125.1234469879130.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20153924.1245361618932.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472865#action_12472865 ] 

Jim Brownfield commented on JBAS-6499:
--------------------------------------

As far as I can tell, just uncommenting the sendNotification fixes this.  I don't know if there are other possible implications to doing that.  Do you want me to fix it?  If so, what do I need to do to get permission?  Thanks.

> jboss.tomcat.connectors.started JMX Notification Missing
> --------------------------------------------------------
>
>                 Key: JBAS-6499
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6499
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.0.GA
>            Reporter: Jim Brownfield
>            Assignee: Remy Maucherat
>
> It appears the jboss.tomcat.connectors.started JMX notification is missing in JBoss 5.0.0.  Looking through the JBoss source code, the TOMCAT_CONNECTORS_STARTED is the static variable containing the message.  That variable seems to only be referenced in org.jboss.web.tomcat.service.deployers.TomcatService.java in a comment within the method startConnectors():
>       /*
>        * TODO: // Notify listeners that connectors have started processing requests sendNotification(new
>        * Notification(TOMCAT_CONNECTORS_STARTED, this, getNextNotificationSequenceNumber()));
>        */

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 18:32:56 2009
From: jira-events at lists.jboss.org (Calvin Lin (JIRA))
Date: Thu, 18 Jun 2009 18:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7037) JBossAS 5.x fails to
 use EJB's
 security domain in jboss.xml when the call is from web container
In-Reply-To: <2821553.1245299576703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2595905.1245364376584.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Calvin Lin updated JBAS-7037:
-----------------------------

    Attachment: ConfigFiles-lib.zip


Additional files needed in JBoss AS directory for testing.
Please read the readme.txt file for details.

> JBossAS 5.x fails to use EJB's security domain in jboss.xml when the call is from web container
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7037
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: Problem found on Windows platform
>            Reporter: Calvin Lin
>            Assignee: Stefan Guilhen
>             Fix For: JBossAS-5.0.2.GA
>
>         Attachments: ConfigFiles-lib.zip, JBAS-jira-authenBug.zip
>
>
> A degredation from JBoss 4.0.x and 4.2.x to JBoss 5.0.1.GA and JBoss 5.1.0.GA.
> We noticed that the JAAS login in EJB container always picks up the Web app's security domain when the client login is originated from a web application client.  The security domain specified in EJB container's jboss.xml is always ignored in this situation.
> The detailed problem description is posted on JBoss forum:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156863

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 18:53:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 18:53:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1660)
 DuplicateIDCacheImpl won't delete records after reload
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10558691.1245365637754.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1660:
-----------------------------------------

    Fix Version/s: 2.0.0.beta3
                       (was: 2.0.0)


> DuplicateIDCacheImpl won't delete records after reload
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.beta3
>
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 18:53:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 18:53:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1660)
 DuplicateIDCacheImpl won't delete records after reload
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12457649.1245365637343.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic reopened JBMESSAGING-1660:
------------------------------------------



> DuplicateIDCacheImpl won't delete records after reload
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.beta3
>
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 18:55:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 18:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1660)
 DuplicateIDCacheImpl won't delete records after reload
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29613233.1245365756621.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1660.
----------------------------------------

    Resolution: Done


> DuplicateIDCacheImpl won't delete records after reload
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Jbm User
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.beta3
>
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 19:33:57 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 18 Jun 2009 19:33:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7033) Upgrade to JBossXACML
	2.0.3.SP2
In-Reply-To: <13425312.1245267716521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4259933.1245368037349.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen closed JBAS-7033.
--------------------------------

    Resolution: Done


Trunk and Branch_5_x have been updated to use JBossXACML 2.0.3.SP2.

> Upgrade to JBossXACML 2.0.3.SP2 
> --------------------------------
>
>                 Key: JBAS-7033
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7033
>             Project: JBoss Application Server
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Upgrade to JBossXACML 2.0.3.SP2
> Branch_5_x, trunk and the branch corresponding to EAP5 (find out what branch is that).
> Just update the component/pom.xml
> Run the   ant   tests-security-basic-unit test target and see if there are regressions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 19:35:56 2009
From: jira-events at lists.jboss.org (John Bebbington (JIRA))
Date: Thu, 18 Jun 2009 19:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2129) The
 WorkingMemoryEventListener
 doesn't set the oldObject for objectUpdated method.
Message-ID: <5650920.1245368156655.JavaMail.jira@cloud.prod.atl2.jboss.com>

The WorkingMemoryEventListener doesn't set the oldObject for objectUpdated method.
----------------------------------------------------------------------------------

                 Key: JBRULES-2129
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2129
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.1.0.M1
            Reporter: John Bebbington
            Assignee: Mark Proctor


The org.drools.event.rule.impl.ObjectEventImpl.java class has a fairly obvious error in it's constructor.

The line:
       object = event.getOldObject();
Needs to be changed to:
       oldObject = event.getOldObject();



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 19:43:57 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Thu, 18 Jun 2009 19:43:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11058259.1245368637036.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472892#action_12472892 ] 

Richard Kennard commented on JBMETA-208:
----------------------------------------

Alexey,

Apologies, I posted the wrong forum link. It should be...

http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157022

...it is not obvious, at first, that this forum link is about the issue either. That's because this issue causes an unusual side effect (ie. none of your beans get registered with JNDI).

I respect your decision whether to a) fix the code or b) fix the EJB3 docs. However, you might want to at least improve the warning around using EJB3 annotations and (accidentally) an EJB2 deployment descriptor. I only stress this because it used to work in JBoss 4.2.3 (which I know was not fully Java EE 5 compliant, but still).

Richard.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 20:57:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 18 Jun 2009 20:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-56) Add tests that
 bootstraps are shutdown in reverse order from start
In-Reply-To: <30621135.1240858006745.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9099153.1245373076428.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBBOOT-56:
--------------------------------------

    Attachment: JBBOOT-56.v2.ALR.patch


> Add tests that bootstraps are shutdown in reverse order from start
> ------------------------------------------------------------------
>
>                 Key: JBBOOT-56
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-56
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-base
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: Unscheduled
>
>         Attachments: JBBOOT-56.v1.patch, JBBOOT-56.v2.ALR.patch
>
>
> Ensure that we are shutting down in proper sequence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 20:59:59 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 18 Jun 2009 20:59:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBOOT-56) Add tests that
 bootstraps are shutdown in reverse order from start
In-Reply-To: <30621135.1240858006745.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19680409.1245373199235.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBBOOT-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472899#action_12472899 ] 

Andrew Lee Rubinger commented on JBBOOT-56:
-------------------------------------------

Attached another patch; discussion/explanation on Forum

> Add tests that bootstraps are shutdown in reverse order from start
> ------------------------------------------------------------------
>
>                 Key: JBBOOT-56
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-56
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-base
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: Unscheduled
>
>         Attachments: JBBOOT-56.v1.patch, JBBOOT-56.v2.ALR.patch
>
>
> Ensure that we are shutting down in proper sequence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 20:59:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 18 Jun 2009 20:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-56) Add tests that
 bootstraps are shutdown in reverse order from start
In-Reply-To: <30621135.1240858006745.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28253663.1245373196498.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBBOOT-56:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238391


> Add tests that bootstraps are shutdown in reverse order from start
> ------------------------------------------------------------------
>
>                 Key: JBBOOT-56
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-56
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-base
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: Unscheduled
>
>         Attachments: JBBOOT-56.v1.patch, JBBOOT-56.v2.ALR.patch
>
>
> Ensure that we are shutting down in proper sequence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 21:52:03 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 21:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1662) Possible
 Performance
 Regression On Small Transactions on AIO if using Linux 2.6.15
Message-ID: <25346013.1245376323276.JavaMail.jira@cloud.prod.atl2.jboss.com>

Possible Performance Regression On Small Transactions on AIO if using Linux 2.6.15
----------------------------------------------------------------------------------

                 Key: JBMESSAGING-1662
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1662
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Clebert Suconic
            Assignee: Tim Fox


Linux 2.6.15 had a bug on nanoSleep. As a result this could hit transactional benchmarks as the minimal buffer timeout would be considered 1 millisecond. 

(This wouldn't bring any problems on scaling up clients)

We are disabling native-timers because of this then.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 21:52:04 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 21:52:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1662) Possible
 Performance
 Regression On Small Transactions on AIO if using Linux 2.6.15
In-Reply-To: <25346013.1245376323276.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9740161.1245376324064.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1662:
-----------------------------------------

        Fix Version/s: 2.0.0.beta3
    Affects Version/s: 2.0.0.beta2


> Possible Performance Regression On Small Transactions on AIO if using Linux 2.6.15
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1662
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1662
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.beta3
>
>
> Linux 2.6.15 had a bug on nanoSleep. As a result this could hit transactional benchmarks as the minimal buffer timeout would be considered 1 millisecond. 
> (This wouldn't bring any problems on scaling up clients)
> We are disabling native-timers because of this then.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 21:52:03 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 21:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1662) Possible
 Performance
 Regression On Small Transactions on AIO if using Linux 2.6.15
In-Reply-To: <25346013.1245376323276.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25732266.1245376323844.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic reassigned JBMESSAGING-1662:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)


> Possible Performance Regression On Small Transactions on AIO if using Linux 2.6.15
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1662
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1662
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.beta3
>
>
> Linux 2.6.15 had a bug on nanoSleep. As a result this could hit transactional benchmarks as the minimal buffer timeout would be considered 1 millisecond. 
> (This wouldn't bring any problems on scaling up clients)
> We are disabling native-timers because of this then.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 21:59:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 21:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1662) Possible
 Performance
 Regression On Small Transactions on AIO if using Linux 2.6.15
In-Reply-To: <25346013.1245376323276.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33408013.1245376796561.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1662.
----------------------------------------

    Resolution: Done


> Possible Performance Regression On Small Transactions on AIO if using Linux 2.6.15
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1662
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1662
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta2
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.beta3
>
>
> Linux 2.6.15 had a bug on nanoSleep. As a result this could hit transactional benchmarks as the minimal buffer timeout would be considered 1 millisecond. 
> (This wouldn't bring any problems on scaling up clients)
> We are disabling native-timers because of this then.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 22:28:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 18 Jun 2009 22:28:56 -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: <28303085.1245378536835.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1661:
-----------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> 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://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.4.GA
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 23:18:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Thu, 18 Jun 2009 23:18:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6777) 'interleaving' prop
 on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4146398.1245381537081.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-6777.
---------------------------------

    Resolution: Done


I have this working in deployments that have the local-transaction value false

> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 23:34:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 18 Jun 2009 23:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (SECURITY-420) JBoss Security
 2.0.3.SP2 Release
In-Reply-To: <14028107.1245268807366.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14612004.1245382496865.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened SECURITY-420:
------------------------------------



SECURITY-415 is causing regressions in AS5

> JBoss Security 2.0.3.SP2 Release
> --------------------------------
>
>                 Key: SECURITY-420
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-420
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 18 23:34:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 18 Jun 2009 23:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (SECURITY-415) ClientLoginModule
 multi-threaded=false should make SecurityContext client side association
In-Reply-To: <12517767.1244524256604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14365380.1245382497004.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened SECURITY-415:
------------------------------------



> ClientLoginModule multi-threaded=false should make SecurityContext client side association
> ------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-415
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-415
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.3.SP1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>
> The ClientLoginModule multi-threaded=false option when missing, should set SecurityContextAssociation.setClient()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 01:13:32 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 19 Jun 2009 01:13:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20651804.1245388412118.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472905#action_12472905 ] 

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

An EJB-JAR with EJB2 ejb-jar.xml and EJB3 annotations should fail to deploy. I'll have a look.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:03:08 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 19 Jun 2009 03:03:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-995) AUTH:
 FixedMembershipToken is
 based on physical address, won't work with logical addresses
Message-ID: <18811572.1245394988966.JavaMail.jira@cloud.prod.atl2.jboss.com>

AUTH: FixedMembershipToken is based on physical address, won't work with logical addresses
------------------------------------------------------------------------------------------

                 Key: JGRP-995
                 URL: https://jira.jboss.org/jira/browse/JGRP-995
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


The authenticate() method attempts to parse the IP address and port of a message's sender and match it to the fixed_members_value list. However, this won't work as the sender's address is a UUID.

SOLUTION #1: fetch the physical address from TP and compare against the physical address (what if we have multiple physical addresses ?)
SOLUTION #2: additional feature: match against the logical name

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:14:08 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 19 Jun 2009 03:14:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26977679.1245395648354.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472922#action_12472922 ] 

Emanuel Muckenhuber commented on JBMETA-208:
--------------------------------------------

There is something like isMetaDataComplete() which is true for ejb2 deployments - so it won't scan for annotations. AFAIK this is also part of the EE spec.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:15:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 19 Jun 2009 03:15:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-996) AUTH: handle multiple
 physical addresses in FixedMembershipToken
Message-ID: <4003443.1245395756979.JavaMail.jira@cloud.prod.atl2.jboss.com>

AUTH: handle multiple physical addresses in FixedMembershipToken
----------------------------------------------------------------

                 Key: JGRP-996
                 URL: https://jira.jboss.org/jira/browse/JGRP-996
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.9




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:39:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 19 Jun 2009 03:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-997) AUTH: incorrect
 matching of src against memberList
Message-ID: <452232.1245397196603.JavaMail.jira@cloud.prod.atl2.jboss.com>

AUTH: incorrect matching of src against memberList
--------------------------------------------------

                 Key: JGRP-997
                 URL: https://jira.jboss.org/jira/browse/JGRP-997
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.6.11




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:48:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 19 Jun 2009 03:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7031) make JMX invoker,
 jmx-console, 
 admin-console, and remote access to Profile Service all use the same
 security domain
In-Reply-To: <112800.1245254636508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5468442.1245397736491.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-7031.
---------------------------------

    Resolution: Done


The profileservice ejbs now use the jmx-console domain and JBossAdmin as the required role

> make JMX invoker, jmx-console, admin-console, and remote access to Profile Service all use the same security domain
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7031
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7031
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> This should be done in all configurations - default, all, etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:53:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 19 Jun 2009 03:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-997) AUTH: incorrect
 matching of src against memberList
In-Reply-To: <452232.1245397196603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26753218.1245398036503.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-997.
---------------------------

    Resolution: Done


> AUTH: incorrect matching of src against memberList
> --------------------------------------------------
>
>                 Key: JGRP-997
>                 URL: https://jira.jboss.org/jira/browse/JGRP-997
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.6.11
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:53:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 19 Jun 2009 03:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-995) AUTH:
 FixedMembershipToken is
 based on physical address, won't work with logical addresses
In-Reply-To: <18811572.1245394988966.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18004004.1245398036636.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-995.
---------------------------

    Resolution: Done


Matching against logical names is left for a later version

> AUTH: FixedMembershipToken is based on physical address, won't work with logical addresses
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-995
>                 URL: https://jira.jboss.org/jira/browse/JGRP-995
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> The authenticate() method attempts to parse the IP address and port of a message's sender and match it to the fixed_members_value list. However, this won't work as the sender's address is a UUID.
> SOLUTION #1: fetch the physical address from TP and compare against the physical address (what if we have multiple physical addresses ?)
> SOLUTION #2: additional feature: match against the logical name

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:56:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 19 Jun 2009 03:56:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-998) AUTH /
 FixedMembershipToken:
 pattern matching and match against logical names
Message-ID: <7649000.1245398217955.JavaMail.jira@cloud.prod.atl2.jboss.com>

AUTH / FixedMembershipToken: pattern matching and match against logical names
-----------------------------------------------------------------------------

                 Key: JGRP-998
                 URL: https://jira.jboss.org/jira/browse/JGRP-998
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.9


#1 Use pattern matching to match hosts against senders, using regular expressions.
#2 Provide matching of logical names in addition to physical addresses

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 03:56:58 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 19 Jun 2009 03:56:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-998) AUTH /
 FixedMembershipToken:
 pattern matching and match against logical names
In-Reply-To: <7649000.1245398217955.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7165718.1245398218079.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-998:
--------------------------

    Priority: Minor  (was: Major)


> AUTH / FixedMembershipToken: pattern matching and match against logical names
> -----------------------------------------------------------------------------
>
>                 Key: JGRP-998
>                 URL: https://jira.jboss.org/jira/browse/JGRP-998
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.9
>
>
> #1 Use pattern matching to match hosts against senders, using regular expressions.
> #2 Provide matching of logical names in addition to physical addresses

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 06:11:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 19 Jun 2009 06:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1851) Investigate
 the failure
 org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
In-Reply-To: <10648726.1245161216783.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31517224.1245406316744.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472943#action_12472943 ] 

jaikiran pai commented on EJBTHREE-1851:
----------------------------------------

Tried this locally by running this single test. The test passes. But given that this testcase consistenly fails on Hudson jobs and Mike, i guess it has something to do with the testcases that have run before this one. I'll try running a "group" of related testcases to see what it shows.

> Investigate the failure org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
> -------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1851
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1851
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: testsuite
>    Affects Versions: 1.1.7
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> The org.jboss.ejb3.test.container.unit.ContainerTestCase consistently fails with:
> javax.naming.NameNotFoundException: Stateful not bound
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
> 	at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
> 	at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> 	at java.lang.Thread.run(Thread.java:595)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> 	at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at org.jboss.ejb3.test.container.unit.ContainerTestCase.testInvocationStatistics(ContainerTestCase.java:93)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
> 	at junit.extensions.TestSetup.run(TestSetup.java:27)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 07:19:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 19 Jun 2009 07:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21071336.1245410396641.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1657:
------------------------------------

        Fix Version/s: 1.4.0.SP3.CP09
                       1.4.5.GA
    Affects Version/s: 1.4.0.SP3.CP08
                       1.4.0.SP3.CP07


> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05, 1.4.0.SP3.CP07, 1.4.0.SP3.CP08
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 07:28:03 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 19 Jun 2009 07:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11205024.1245410883643.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472959#action_12472959 ] 

Howard Gao commented on JBMESSAGING-1657:
-----------------------------------------

The fix:

In GroupMember.multicastConstrol, where ever a multicast message is not received be any member, we do a check on the member's status. If the member is actually dead, it can be safely ignored. the code is like:

   if (!rsp.wasReceived())
   {
      if (!rsp.wasSuspected())
      {
         throw new IllegalStateException(this + " response not received from " + rsp.getSender() + " - there may be others");
      }
   }

where the rsp.wasSuspected() can be used to detected whether the member is really dead or not. (I consulted jgroup lead Bela Ban).



> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05, 1.4.0.SP3.CP07, 1.4.0.SP3.CP08
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 07:33:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 19 Jun 2009 07:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1657)
 IllegalStateException upon cluster fail-over
In-Reply-To: <14524465.1245184736719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27236793.1245411236580.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1657.
-----------------------------------

    Resolution: Done


> IllegalStateException upon cluster fail-over
> --------------------------------------------
>
>                 Key: JBMESSAGING-1657
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1657
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP05, 1.4.0.SP3.CP07, 1.4.0.SP3.CP08
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 127.0.0.1.log, 127.0.0.2.log, client.log, JmsTest.java
>
>
> I set up two cluster nodes like so:
> 1) unzipped fresh JBoss EAP 4.3 CP04
> 2) renamed <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml to hsqldb-persistence-service.xml.rej
> 3) copied <JBOSS_HOME>/docs/examples/jms/mysql-persistence-service.xml to <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar
> 4) Modified the "Clustered" attribute to be "true" in <JBOSS_HOME>/server/default/deploy/jboss-messaging.sar/mysql-persistence-service.xml
> 5) copied <JBOSS_HOME>/docs/examples/jca/mysql-ds.xml to <JBOSS_HOME>/server/default/deploy and changed the jndi-name to "DefaultDS" and pointed it at my local MySQL
> 6) copied MySQL driver to <JBOSS_HOME>/server/default/lib
> 7) copied jgroups.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib
> 8) copied <JBOSS_HOME> to <JBOSS_HOME2>
> 9) Start first instance with "./run.sh -c default -b 127.0.0.1 -Djboss.messaging.ServerPeerID=1"
> 10) Start second instance with "./run.sh -c default -b 127.0.0.2 -Djboss.messaging.ServerPeerID=2"
> Then I ran the test (which is attached as JmsTest.java)
>  -Start test client connecting to 127.0.0.1
>  -Observe client log filling up with "."
>  -Drop JBoss running on 127.0.0.1 (using kill -9 <pid>)
>  -Client fails with org.jboss.jms.exception.MessagingJMSException (see log attached as client.log)
>  -Observe java.lang.IllegalStateException on the 127.0.0.2 (attached as 127.0.0.2.log)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 07:45:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 19 Jun 2009 07:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28629176.1245411956489.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472962#action_12472962 ] 

jaikiran pai commented on EJBTHREE-1852:
----------------------------------------

We have this working tutorial http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/docs/tutorial/interceptor/META-INF/ejb-jar.xml. Moreover, the line 433 in InterceptorInfoRepository is unlikely to have a NPE. Are you sure, you are not packaging any old versions of jboss jars files within your application? Also, please create a forum thread in the EJB3 user forum so that we can discuss this there http://www.jboss.org/index.html?module=bb&op=viewforum&f=221

> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: deployers, ejb3, interceptors
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 07:51:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 19 Jun 2009 07:51:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13832520.1245412317312.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1852:
-----------------------------------

    Component/s: core
                     (was: interceptors)
                     (was: deployers)
                     (was: ejb3)


> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 08:02:06 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 19 Jun 2009 08:02:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1660)
 DuplicateIDCacheImpl won't delete records after reload
In-Reply-To: <7365259.1245316677091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1748233.1245412926878.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12472971#action_12472971 ] 

Tim Fox commented on JBMESSAGING-1660:
--------------------------------------

Hey Bijith- It's not related to the issue but I had a couple of comments on your test program:

I noticed you were using ObjectMessage - ObjectMessage in JMS is the slowest message type you can choose (see the perf tuning section in the userguide) since it uses Java serialization. If you're just sending  bytes then you're better off using a BytesMessage or even better, using the core API (not JMS).

Also I noticed you were manually calling acknowledge() on your messages event though the session is auto_acknowledge - in this case the calls to acknowledge() will be ignored. Bear in mind AUTO_ACK is also the slowest ack mode in JMS you can use.

Cheers

> DuplicateIDCacheImpl won't delete records after reload
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1660
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1660
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2
>         Environment: Windows Vista SP1 32 bit, 2 GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0.beta3
>
>         Attachments: jbm-configuration.xml, jbm-jms.xml, src.zip
>
>
> Hi,
> I am using JBM 2.0.0.BETA1 stand alone server.
> I have added 1 million messages in a queue with following page settings in jbm-configuration.xml
> <paging-max-global-size-bytes>52428800</paging-max-global-size-bytes>
> <global-page-size>10485760</global-page-size>
> When I try to consume these messages it is observed that sometimes (especially when using Session.CLIENT_ACKNOWLEDGE), the journal folder size grows to 2 to 3GBs and stays there even after client has consumed all the messages . When I checked the Paging/ folder, it is empty (as expected). It seems the Journal garbage collector is not correctly cleaning up the files from journal/ folder.
> Now, the issue is that, when I try to restart the server, it fails and throws OutOfMemroyException . I am able to successfully restart the server after manually deleting all journal files.
> I am not sure why server is loading the journal files on start up when all the messages are already consumed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 08:49:56 2009
From: jira-events at lists.jboss.org (Prem Stephen (JIRA))
Date: Fri, 19 Jun 2009 08:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2130) DSL Bug while
 creating comparison combinations
Message-ID: <17065276.1245415796493.JavaMail.jira@cloud.prod.atl2.jboss.com>

DSL Bug while creating comparison combinations
----------------------------------------------

                 Key: JBRULES-2130
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2130
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.1.FINAL
         Environment: I tried building the DSL using Guvnor

            Reporter: Prem Stephen
            Assignee: Mark Proctor
            Priority: Blocker


In http://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/drools-expert/html_single/index.html#d0e5595, section 4.10.4 - I am expanding on the following syntax example for structuring combinations in the DSL.

In my example, I have

[when]There is a Contact with=Contact()
[when]- age is less than {age}=age < {age}
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}   <-------------------- this line does not work
[when]- age is foo than or equal to {age}=age <= {age}

and my rule is

when
	There is a Contact with
	- age is foo than or equal to 35
	
then
	Log : "Contact exists Test";

Now, the line that does not work is because it shares the start "age is less than " with an earlier DSL.
Replacing "less" with "foo" works for this reason.
I think the parsing needs to be fixed to look at the whole sentence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 08:56:56 2009
From: jira-events at lists.jboss.org (Prem Stephen (JIRA))
Date: Fri, 19 Jun 2009 08:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2131) More flexible
 DSL: sharing of comparison operators between attributes
Message-ID: <14527259.1245416216489.JavaMail.jira@cloud.prod.atl2.jboss.com>

More flexible DSL: sharing of comparison operators between attributes
---------------------------------------------------------------------

                 Key: JBRULES-2131
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2131
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.1.FINAL
         Environment: I tried building the DSL using Guvnor

            Reporter: Prem Stephen
            Assignee: Mark Proctor
            Priority: Blocker


In http://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/drools-expert/html_single/index.html#d0e5595, section 4.10.4 - I am expanding on the following syntax example for structuring combinations in the DSL.

In my example, I have

[when]There is a Contact with=Contact()
[when]- age is less than {age}=age < {age}
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}   <-------------------- this line does not work
[when]- age is foo than or equal to {age}=age <= {age}

and my rule is

when
	There is a Contact with
	- age is foo than or equal to 35
	
then
	Log : "Contact exists Test";

Now, the line that does not work is because it shares the start "age is less than " with an earlier DSL.
Replacing "less" with "foo" works for this reason.
I think the parsing needs to be fixed to look at the whole sentence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 09:03:05 2009
From: jira-events at lists.jboss.org (Prem Stephen (JIRA))
Date: Fri, 19 Jun 2009 09:03:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2131) More flexible
 DSL: sharing of comparison operators between attributes
In-Reply-To: <14527259.1245416216489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31947061.1245416585821.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Prem Stephen updated JBRULES-2131:
----------------------------------

                Issue Type: Feature Request  (was: Bug)
    Workaround Description:   (was: After much experimentation, I found that switching the lines so that "less than or equal to" comes before "less than" does not break.
for eg, this works

[when]There is a Contact with=Contact()
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}
[when]- age is less than {age}=age < {age}

If this cannot be fixed, this quirky behaviour should at the very least be documented.
)
               Environment:     (was: I tried building the DSL using Guvnor
)
               Description: 
In the following DSL
[when]There is a Contact with=Contact()
[when]- age is greater than or equal to {age}=age > {age}
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}
[when]- age is less than {age}=age < {age}

Now, if I had 10 attributes of type int, then currently from what I could read in my documentation I need to recreate these lines for each of these 10 attributes.

Hope about a DSL that is more granular, similar to the one below ( i am just putting this up )
[when][operator]is less than="<"
[when][operator]is less than or equal to ="<="
[when][operator]is greater than=">"
[when][operator]is greater than or equal to =">="

then, I should be able to state that since age is a int, it can use the above operators.
A country, being a String, should not be able to use these operators.

  was:
In http://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/drools-expert/html_single/index.html#d0e5595, section 4.10.4 - I am expanding on the following syntax example for structuring combinations in the DSL.

In my example, I have

[when]There is a Contact with=Contact()
[when]- age is less than {age}=age < {age}
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}   <-------------------- this line does not work
[when]- age is foo than or equal to {age}=age <= {age}

and my rule is

when
	There is a Contact with
	- age is foo than or equal to 35
	
then
	Log : "Contact exists Test";

Now, the line that does not work is because it shares the start "age is less than " with an earlier DSL.
Replacing "less" with "foo" works for this reason.
I think the parsing needs to be fixed to look at the whole sentence.

                  Priority: Critical  (was: Blocker)
                Workaround:   (was: [Workaround Exists])


> More flexible DSL: sharing of comparison operators between attributes
> ---------------------------------------------------------------------
>
>                 Key: JBRULES-2131
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2131
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Prem Stephen
>            Assignee: Mark Proctor
>            Priority: Critical
>
> In the following DSL
> [when]There is a Contact with=Contact()
> [when]- age is greater than or equal to {age}=age > {age}
> [when]- age is greater than {age}=age > {age}
> [when]- age is less than or equal to {age}=age <= {age}
> [when]- age is less than {age}=age < {age}
> Now, if I had 10 attributes of type int, then currently from what I could read in my documentation I need to recreate these lines for each of these 10 attributes.
> Hope about a DSL that is more granular, similar to the one below ( i am just putting this up )
> [when][operator]is less than="<"
> [when][operator]is less than or equal to ="<="
> [when][operator]is greater than=">"
> [when][operator]is greater than or equal to =">="
> then, I should be able to state that since age is a int, it can use the above operators.
> A country, being a String, should not be able to use these operators.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 09:14:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 19 Jun 2009 09:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2131) More flexible DSL:
 sharing of comparison operators between attributes
In-Reply-To: <14527259.1245416216489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19730158.1245417297168.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2131.
----------------------------------

    Fix Version/s: 5.0.1.FINAL
       Resolution: Rejected
         Assignee: Edson Tirelli  (was: Mark Proctor)


This is already possible in the DSL. Just a matter of properly constructing the grammar.

[when][]is less than=<
[when][]- {field:\w*} {operator} {value:\d*}={field} {operator} {value} 

And so on... the order of the entries in the grammar is important.

> More flexible DSL: sharing of comparison operators between attributes
> ---------------------------------------------------------------------
>
>                 Key: JBRULES-2131
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2131
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Prem Stephen
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.0.1.FINAL
>
>
> In the following DSL
> [when]There is a Contact with=Contact()
> [when]- age is greater than or equal to {age}=age > {age}
> [when]- age is greater than {age}=age > {age}
> [when]- age is less than or equal to {age}=age <= {age}
> [when]- age is less than {age}=age < {age}
> Now, if I had 10 attributes of type int, then currently from what I could read in my documentation I need to recreate these lines for each of these 10 attributes.
> Hope about a DSL that is more granular, similar to the one below ( i am just putting this up )
> [when][operator]is less than="<"
> [when][operator]is less than or equal to ="<="
> [when][operator]is greater than=">"
> [when][operator]is greater than or equal to =">="
> then, I should be able to state that since age is a int, it can use the above operators.
> A country, being a String, should not be able to use these operators.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 10:09:56 2009
From: jira-events at lists.jboss.org (John Gilbert (JIRA))
Date: Fri, 19 Jun 2009 10:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14408090.1245420596496.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473003#action_12473003 ] 

John Gilbert commented on EJBTHREE-1852:
----------------------------------------

no, there are no older jar versions.
just took an ear that worked in 4.2.3 and trying to upgrade.
in the debugger bindingXml.interceptorClasses is null

i think the difference between the tutorial and my descriptor is that i am using interceptor-order for the default interceptors.
this was the only way this worked with EJB3StandaloneBootstrap.

> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 10:41:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 10:41:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6989) Fix
 compatibility-matrix tests in Branch_5_x
In-Reply-To: <15176372.1243564628200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2211152.1245422517531.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6989:
---------------------------------


[waitfor] WARNING: Could not find expected boot lib /TEST/Branch_5_x/tools/lib/trove.jar
  [waitfor] Failed to boot JBoss:
  [waitfor] java.lang.IllegalArgumentException: Specified implementation class could not be found: org.jboss.bootstrap.impl.as.server.JBossASServerImpl on ClassLoader java.net.URLClassLoader at 7a5a19
  [waitfor]     at org.jboss.bootstrap.spi.factory.GenericFactory.createInstance(GenericFactory.java:92)
  [waitfor]     at org.jboss.bootstrap.spi.factory.ServerFactory.createServer(ServerFactory.java:83)
  [waitfor]     at org.jboss.Main.boot(Main.java:364)
  [waitfor]     at org.jboss.Main$1.run(Main.java:727)
  [waitfor]     at java.lang.Thread.run(Thread.java:595)
  [waitfor] Caused by: java.lang.ClassNotFoundException: org.jboss.bootstrap.impl.as.server.JBossASServerImpl
  [waitfor]     at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
  [waitfor]     at java.security.AccessController.doPrivileged(Native Method)
  [waitfor]     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
  [waitfor]     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
  [waitfor]     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
  [waitfor]     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
  [waitfor]     at java.lang.Class.forName0(Native Method)
  [waitfor]     at java.lang.Class.forName(Class.java:242)
  [waitfor]     at org.jboss.bootstrap.spi.factory.GenericFactory.createInstance(GenericFactory.java:88)


> Fix compatibility-matrix tests in Branch_5_x
> --------------------------------------------
>
>                 Key: JBAS-6989
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6989
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Need to sync with new bootstrap implementation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 10:45:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 10:45:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6968)
 org.jboss.test.spring.test.SpringClusterTestCase failing with IBM JDK 1.5
In-Reply-To: <32698421.1243001398195.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28474768.1245422757628.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6968:
---------------------------------


The fix has been commited to the JBPAPP_5_0 branch, rev 90367.   Need to commit to Branch_5_x and trunk.

> org.jboss.test.spring.test.SpringClusterTestCase failing with IBM JDK 1.5
> -------------------------------------------------------------------------
>
>                 Key: JBAS-6968
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6968
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: spring-server.log
>
>
> org.jboss.test.spring.test.SpringClusterTestCase is failing with this message:
> testStandalone	Failure	N/A
> junit.framework.AssertionFailedError
> 	at org.jboss.test.spring.test.SpringClusterTestCase.testStandalone(SpringClusterTestCase.java:43)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> In the server log you can see:
> ...
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/lib/spring-cluster-pojos.jar/" is in error due to the following reason(s): java.lang.ClassNotFoundException: net.jcip.annotations.ThreadSafe
> ...
> Which shows that it is again the same problem with net.jcip.annotations.ThreadSafe missing in IBM JDK as discussed here JBAS-6934 and JBAS-6428.
> Solution: Ensure that jcip-annotations.jar gets copied to server/springdeployer/lib/ when the config is created.
> A. Add jcip-annotations.jar to server/default/lib (it is 2.6 KB) - springdeployer is created out of default
> B. Change testsuite/build.xml to make ant copy jcip-annotations.jar from server/all/lib/ to server/springdeployer/lib/ - don't know how to do that easily
> A. seems easier to do.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 10:45:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 10:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6967)
 org.jboss.test.security.test.HttpsUnitTestCase failing with IBM JDK
In-Reply-To: <27953188.1242999477645.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23692014.1245422756791.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6967:
---------------------------------


This has been fixed in the JBPAPP_5_0 branch, rev 90367.  Need to commit to Branch_5_x and trunk.

> org.jboss.test.security.test.HttpsUnitTestCase failing with IBM JDK
> -------------------------------------------------------------------
>
>                 Key: JBAS-6967
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6967
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: TEST-org.jboss.test.security.test.HttpsUnitTestCase-tests-security-basic-unit.xml
>
>
> When running the AS testsuite, this test case shows an error:
> org.jboss.test.security.test.HttpsUnitTestCase
> The error message is:
> unknown	Error	N/A
> java.lang.NullPointerException
> 	at java.security.Security.insertProviderAt(Security.java:357)
> 	at java.security.Security.addProvider(Security.java:406)
> 	at org.jboss.test.security.test.HttpsUnitTestCase$1.setUp(HttpsUnitTestCase.java:171)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> When you look in the source code, this is the line where it fails:
> Security.addProvider(SecurityProviderUtil.getJSSEProvider());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 10:47:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 10:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6962)
 org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
In-Reply-To: <994948.1242838745393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25508177.1245422876614.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6962:
---------------------------------


The fix has been commited to the JBPAPP_5_0 branch, rev 90367.   Need to commit to Branch_5_x and trunk.


> org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
> ----------------------------------------------------------------------
>
>                 Key: JBAS-6962
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6962
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: TEST-org.jboss.test.cmp2.commerce.CompleteUnitTestCase.xml
>
>
> With IBM JDK 1.6 the test testJBossQL fails with this message:
> Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> junit.framework.AssertionFailedError: Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> 	at org.jboss.test.cmp2.commerce.QueryTest.testJBossQL(QueryTest.java:169)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)
> It's strange that with IBM 1.6 the failure does not happen in that test, but in different - testEJBQL:
> expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> junit.framework.ComparisonFailure: expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> 	at org.jboss.test.cmp2.commerce.QueryTest.testEJBQL(QueryTest.java:329)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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:193)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Fri Jun 19 10:49:56 2009
From: jira-events at lists.jboss.org (Prem Stephen (JIRA))
Date: Fri, 19 Jun 2009 10:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2132) Patch: Docs:
 Expert: Rule Language chapter: DSL Section
Message-ID: <19253271.1245422996891.JavaMail.jira@cloud.prod.atl2.jboss.com>

Patch: Docs: Expert: Rule Language chapter: DSL Section
-------------------------------------------------------

                 Key: JBRULES-2132
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2132
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.1.FINAL
            Reporter: Prem Stephen
            Assignee: Edson Tirelli
            Priority: Critical
             Fix For: 5.0.1.FINAL


In the following DSL
[when]There is a Contact with=Contact()
[when]- age is greater than or equal to {age}=age > {age}
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}
[when]- age is less than {age}=age < {age}

Now, if I had 10 attributes of type int, then currently from what I could read in my documentation I need to recreate these lines for each of these 10 attributes.

Hope about a DSL that is more granular, similar to the one below ( i am just putting this up )
[when][operator]is less than="<"
[when][operator]is less than or equal to ="<="
[when][operator]is greater than=">"
[when][operator]is greater than or equal to =">="

then, I should be able to state that since age is a int, it can use the above operators.
A country, being a String, should not be able to use these operators.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 10:51:56 2009
From: jira-events at lists.jboss.org (Prem Stephen (JIRA))
Date: Fri, 19 Jun 2009 10:51:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2132) Patch: Docs:
 Expert: Rule Language chapter: DSL Section
In-Reply-To: <19253271.1245422996891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4329811.1245423116861.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Prem Stephen updated JBRULES-2132:
----------------------------------

     Issue Type: Support Patch  (was: Feature Request)
    Description: 
I have added additional documentation for DSL and am submitting 2 files.
The one marked "new" has my changes.
The one I used to modify is also attached, for diff, if needed

  was:
In the following DSL
[when]There is a Contact with=Contact()
[when]- age is greater than or equal to {age}=age > {age}
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}
[when]- age is less than {age}=age < {age}

Now, if I had 10 attributes of type int, then currently from what I could read in my documentation I need to recreate these lines for each of these 10 attributes.

Hope about a DSL that is more granular, similar to the one below ( i am just putting this up )
[when][operator]is less than="<"
[when][operator]is less than or equal to ="<="
[when][operator]is greater than=">"
[when][operator]is greater than or equal to =">="

then, I should be able to state that since age is a int, it can use the above operators.
A country, being a String, should not be able to use these operators.

        Affects: [Documentation (Ref Guide, User Guide, etc.)]


> Patch: Docs: Expert: Rule Language chapter: DSL Section
> -------------------------------------------------------
>
>                 Key: JBRULES-2132
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2132
>             Project: JBoss Drools
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Prem Stephen
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.0.1.FINAL
>
>
> I have added additional documentation for DSL and am submitting 2 files.
> The one marked "new" has my changes.
> The one I used to modify is also attached, for diff, if needed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 10:53:56 2009
From: jira-events at lists.jboss.org (Prem Stephen (JIRA))
Date: Fri, 19 Jun 2009 10:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2132) Patch: Docs:
 Expert: Rule Language chapter: DSL Section
In-Reply-To: <19253271.1245422996891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33337765.1245423236768.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Prem Stephen updated JBRULES-2132:
----------------------------------

    Attachment: Section-DSL.xml
                Section-DSL-new.xml


> Patch: Docs: Expert: Rule Language chapter: DSL Section
> -------------------------------------------------------
>
>                 Key: JBRULES-2132
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2132
>             Project: JBoss Drools
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Prem Stephen
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.0.1.FINAL
>
>         Attachments: Section-DSL-new.xml, Section-DSL.xml
>
>
> I have added additional documentation for DSL and am submitting 2 files.
> The one marked "new" has my changes.
> The one I used to modify is also attached, for diff, if needed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 11:09:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 19 Jun 2009 11:09:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMETA-209) jboss-metadata
 trunk test compilation fails in JDK5
In-Reply-To: <9131641.1245260636508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21125558.1245424197106.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger reopened JBMETA-209:
----------------------------------------



Reopening until merged into the new split metadata

> jboss-metadata trunk test compilation fails in JDK5
> ---------------------------------------------------
>
>                 Key: JBMETA-209
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-209
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.0.2.Beta2
>
>
> [INFO] Compilation failure
> /home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
> symbol  : method stringPropertyNames()
> location: class java.util.Properties
> /home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
> symbol  : method stringPropertyNames()
> location: class java.util.Properties

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 11:47:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 11:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6989) Fix
 compatibility-matrix tests in Branch_5_x
In-Reply-To: <15176372.1243564628200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8096317.1245426476522.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6989.
----------------------------------

    Resolution: Done


added  java.endorsed.dirs to start-jboss

> Fix compatibility-matrix tests in Branch_5_x
> --------------------------------------------
>
>                 Key: JBAS-6989
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6989
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Need to sync with new bootstrap implementation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 12:59:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 19 Jun 2009 12:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-531) Build classpaths
 directly against jars in local maven repository
In-Reply-To: <6026725.1243637396349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6147270.1245430796717.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier reassigned JBBUILD-531:
---------------------------------

    Assignee: Paul Gier


> Build classpaths directly against jars in local maven repository
> ----------------------------------------------------------------
>
>                 Key: JBBUILD-531
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-531
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the testsuite uses the jars in thirdparty.  Instead the paths in the testsuite should directly reference jars in the local maven repository directory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 13:04:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 19 Jun 2009 13:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-419) Enable testsuite
 to run against maven generated artifacts.
In-Reply-To: <20791453.1189779191245.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26254461.1245431096414.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-419:
------------------------------

        Parent: JBBUILD-529
    Issue Type: Sub-task  (was: Task)


> Enable testsuite to run against maven generated artifacts.
> ----------------------------------------------------------
>
>                 Key: JBBUILD-419
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-419
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Once maven is able to generate matching artifacts for the ant build, the testsuite will have to be run against the maven generated stuff.  This will probably involve some modifications to the testsuite.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 14:45:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 14:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6966) Some tests fail
 with IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
In-Reply-To: <28786754.1242998527053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21389103.1245437156794.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473072#action_12473072 ] 

Shelly McGowan commented on JBAS-6966:
--------------------------------------

IBM JDK 5 nor 6 supports specifying SSLv2Hello:
http://www.ibm.com/developerworks/java/jdk/security/60/secguides/jsse2Docs/JSSE2RefGuide.html#knowndiffsun
http://www.ibm.com/developerworks/java/jdk/security/50/secguides/jsse2Docs/JSSE2RefGuide.html#knowndiffsun
Specifically,
IBM implementation supports the following protocols: SSL, SSLv3, TLS, TLSv1, and SSL_TLS for engine class SSLContext or the API setEnabledProtocols in the SSLSocket or SSLServerSocket classes. It does not support specifying SSLv2Hello. A server side connection always accepts an SSLv2Hello. The IBM SSLContext getInstance factory method can be used to control which protocols actually get enabled for an SSL connection. Using the SSLContext getInstance or the setEnabledProtocols method give the same result. The Sun JSSE controls which protocols are actually enabled for an SSL connection through setEnabledProtocols.

> Some tests fail with IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
> -----------------------------------------------------------------------------
>
>                 Key: JBAS-6966
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6966
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: SSLv2Hello-error
>
>
> Some tests in the testsuite are failing due to IBM JDK not supporting the SSLv2Hello protocol:
> 15:10:46,727 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=invoker,socketType=SSLSocketFactory,type=jrmp,wantsClientAuth=true state=Create mode=Manual requiredState=Installed
> java.lang.IllegalArgumentException: SSLv2Hello
> 	at com.ibm.jsse2.mb.a(mb.java:24)
> 	at com.ibm.jsse2.lb.<init>(lb.java:41)
> 	at com.ibm.jsse2.hc.setEnabledProtocols(hc.java:57)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:267)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:226)
> 	at org.jboss.security.ssl.RMISSLServerSocketFactory.createServerSocket(RMISSLServerSocketFactory.java:120)
> 	at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:638)
> 	at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:272)
> 	at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:219)
> 	at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:398)
> ...
> This problem was previously reported as JBPAPP-626 but never fixed. I'm creating a new JIRA since it now affects more testcases.
> These testcases fail:
> org.jboss.test.jrmp.test.CustomSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLFailuresSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLSocketsUnitTestCase
> org.jboss.test.pooled.test.SSLSocketsUnitTestCase
> We can still leave it as it is - meaning documenting these failures as known issues with IBM JDK. I just wanted to make sure we know about it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 15:10:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 15:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6966) Some tests fail with
 IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
In-Reply-To: <28786754.1242998527053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3574770.1245438656961.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6966:
---------------------------------

    Affects: [Documentation (Ref Guide, User Guide, etc.), Release Notes]


> Some tests fail with IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
> -----------------------------------------------------------------------------
>
>                 Key: JBAS-6966
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6966
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: SSLv2Hello-error
>
>
> Some tests in the testsuite are failing due to IBM JDK not supporting the SSLv2Hello protocol:
> 15:10:46,727 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=invoker,socketType=SSLSocketFactory,type=jrmp,wantsClientAuth=true state=Create mode=Manual requiredState=Installed
> java.lang.IllegalArgumentException: SSLv2Hello
> 	at com.ibm.jsse2.mb.a(mb.java:24)
> 	at com.ibm.jsse2.lb.<init>(lb.java:41)
> 	at com.ibm.jsse2.hc.setEnabledProtocols(hc.java:57)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:267)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:226)
> 	at org.jboss.security.ssl.RMISSLServerSocketFactory.createServerSocket(RMISSLServerSocketFactory.java:120)
> 	at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:638)
> 	at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:272)
> 	at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:219)
> 	at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:398)
> ...
> This problem was previously reported as JBPAPP-626 but never fixed. I'm creating a new JIRA since it now affects more testcases.
> These testcases fail:
> org.jboss.test.jrmp.test.CustomSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLFailuresSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLSocketsUnitTestCase
> org.jboss.test.pooled.test.SSLSocketsUnitTestCase
> We can still leave it as it is - meaning documenting these failures as known issues with IBM JDK. I just wanted to make sure we know about it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 15:12:56 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 19 Jun 2009 15:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6966) Some tests fail
 with IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
In-Reply-To: <28786754.1242998527053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5370508.1245438776603.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473074#action_12473074 ] 

Anil Saldhana commented on JBAS-6966:
-------------------------------------

Lets deprecate SSLv2

> Some tests fail with IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
> -----------------------------------------------------------------------------
>
>                 Key: JBAS-6966
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6966
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: SSLv2Hello-error
>
>
> Some tests in the testsuite are failing due to IBM JDK not supporting the SSLv2Hello protocol:
> 15:10:46,727 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=invoker,socketType=SSLSocketFactory,type=jrmp,wantsClientAuth=true state=Create mode=Manual requiredState=Installed
> java.lang.IllegalArgumentException: SSLv2Hello
> 	at com.ibm.jsse2.mb.a(mb.java:24)
> 	at com.ibm.jsse2.lb.<init>(lb.java:41)
> 	at com.ibm.jsse2.hc.setEnabledProtocols(hc.java:57)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:267)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:226)
> 	at org.jboss.security.ssl.RMISSLServerSocketFactory.createServerSocket(RMISSLServerSocketFactory.java:120)
> 	at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:638)
> 	at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:272)
> 	at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:219)
> 	at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:398)
> ...
> This problem was previously reported as JBPAPP-626 but never fixed. I'm creating a new JIRA since it now affects more testcases.
> These testcases fail:
> org.jboss.test.jrmp.test.CustomSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLFailuresSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLSocketsUnitTestCase
> org.jboss.test.pooled.test.SSLSocketsUnitTestCase
> We can still leave it as it is - meaning documenting these failures as known issues with IBM JDK. I just wanted to make sure we know about it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 16:04:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 19 Jun 2009 16:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6934) Tests in
 org.jboss.test.cluster failing with IBM JDK 1.5 - Failed to start
 cluster/http/jboss-web-test-service.xml
In-Reply-To: <23484241.1242648377491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13732568.1245441896867.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6934:
---------------------------------


Added <path refid="net.jcip.classpath"/> to library.classpath in JBPAPP_5_0 branch, rev 90479.  Will resolve once committed to trunk.

> Tests in org.jboss.test.cluster failing with IBM JDK 1.5 - Failed to start cluster/http/jboss-web-test-service.xml
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6934
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6934
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>
> Some clustered tests are failing with this error message:
> Failed to start cluster/http/jboss-web-test-service.xml
> org.jboss.cache.pojo.PojoCacheException: Failed to start cluster/http/jboss-web-test-service.xml
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.<init>(PojoCacheImpl.java:63)
> 	at org.jboss.cache.pojo.PojoCacheFactory.createCache(PojoCacheFactory.java:42)
> 	at org.jboss.test.cluster.testutil.SessionTestUtil.getConfiguration(SessionTestUtil.java:147)
> 	at org.jboss.test.cluster.testutil.SessionTestUtil.createCache(SessionTestUtil.java:136)
> 	at org.jboss.test.cluster.testutil.CacheConfigTestSetup.setUp(CacheConfigTestSetup.java:84)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: org.jboss.cache.config.ConfigurationException: Unable to build interceptor chain
> 	at org.jboss.cache.factories.InterceptorChainFactory.construct(InterceptorChainFactory.java:229)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:318)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.DefaultCacheFactory.bootstrap(DefaultCacheFactory.java:155)
> 	at org.jboss.cache.DefaultCacheFactory.createAndWire(DefaultCacheFactory.java:141)
> 	at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:120)
> 	at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:93)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.<init>(PojoCacheImpl.java:58)
> Caused by: java.lang.TypeNotPresentException: Type net.jcip.annotations.ThreadSafe not present
> 	at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:38)
> 	at com.ibm.oti.reflect.AnnotationHelper.getDeclaredAnnotations(AnnotationHelper.java:50)
> 	at java.lang.Class.getDeclaredAnnotations(Class.java:1620)
> 	at java.lang.Class.getAnnotations(Class.java:1581)
> 	at java.lang.Class.getAnnotation(Class.java:1561)
> 	at java.lang.Class.isAnnotationPresent(Class.java:1648)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:252)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.InterceptorChainFactory.createInterceptor(InterceptorChainFactory.java:60)
> 	at org.jboss.cache.factories.InterceptorChainFactory.buildInterceptorChain(InterceptorChainFactory.java:75)
> 	at org.jboss.cache.factories.InterceptorChainFactory.construct(InterceptorChainFactory.java:225)
> Caused by: java.lang.ClassNotFoundException: net.jcip.annotations.ThreadSafe
> 	at java.lang.Class.forName(Class.java:163)
> 	at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:33)
> This is the list of the tests failing because of this: 
> org.jboss.test.cluster.defaultcfg.simpleweb.test.AttributeBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.BuddyReplicationFailoverUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.BuddyReplicationToPassivatedSessionUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.ClusteredSessionNotificationPolicyTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.FieldBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.JBossCacheManagerConfigurationUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.ReplicationToPassivatedSessionUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionCountUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionExpirationUnitTestCase
> In total it causes 29 failures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 16:19:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 19 Jun 2009 16:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21636392.1245442796624.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473088#action_12473088 ] 

Andrew Lee Rubinger commented on EJBTHREE-995:
----------------------------------------------

Discussed w/ Gavin; we'll write up an integration test which includes AS, then close out if still not present.  Then notify Seam team to remove workaround hacks in https://anonsvn.jboss.org/repos/seam/trunk/src/main/java/org/jboss/seam/transaction/EjbSynchronizations.java

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 18:10:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 19 Jun 2009 18:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-6777) 'interleaving' prop
 on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16241488.1245449456687.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened JBAS-6777:
--------------------------------



Using EAP branch r90482, the 'interleaving' prop still gets reset to false by the Profile Service after I set it to true via a component update. I tried with both an XA Datasource and a Tx Connection Factory with XA enabled. Did you forget to check the fix into the EAP branch?


> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 18:32:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 19 Jun 2009 18:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6777) 'interleaving'
 prop on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6156479.1245450776783.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473099#action_12473099 ] 

Scott M Stark commented on JBAS-6777:
-------------------------------------

Yes, its in the https://svn.jboss.org/repos/jbossas/branches/JBPAPP_5_0 and the test is validating that the interleaving property is true on the underlying component:

      // Query the interleaving 
      ManagementView mgtView = getManagementView();
      ComponentType type = KnownComponentTypes.DataSourceTypes.XA.getType();
      ManagedComponent txcf = mgtView.getComponent(jndiName, type);
      assertNotNull(txcf);
      ManagedProperty interleaving = txcf.getProperty("interleaving");
      assertNotNull("interleaving", interleaving);
      MetaValue interleavingMV = interleaving.getValue();
      assertNotNull("interleaving.value", interleavingMV);
      assertEquals("interleaving.value is true", SimpleValueSupport.wrap(Boolean.TRUE), interleavingMV);

Can you attach the ds.xml file that is showing the false value.


> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 18:49:08 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 19 Jun 2009 18:49:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6777) 'interleaving'
 prop on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14485549.1245451748079.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473102#action_12473102 ] 

Ian Springer commented on JBAS-6777:
------------------------------------

For an existing ds.xml that contains the <interleaving/> tag, the interleaving managed prop is true; so that part of it appears to be fixed. The issue that still exists is that when I call updatecomponent() on the management view and then load() on the management view, the managed prop's value has been reset to false. Similarly, when I have an existing datasource or conn factory with interleaving set to false, when I try to change it to true via the PS and then reload the view, its value is still false.

> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 19 19:22:56 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 19 Jun 2009 19:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6777) 'interleaving'
 prop on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14124040.1245453776612.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473104#action_12473104 ] 

Scott M Stark commented on JBAS-6777:
-------------------------------------

Ok, I'll create a test that attempts to change the value from false to true.


> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 00:02:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 00:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6720) Make sure that the
 metrics for
 Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as
 ViewUse.STATISTIC
In-Reply-To: <7508166.1238615242987.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18971227.1245470577000.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473109#action_12473109 ] 

Jason T. Greene commented on JBAS-6720:
---------------------------------------

Farah, I looked into the questions you asked (finally)

Count Delta
-------------------
This metric returns the difference in count since the last read of Count Delta. So if you call it twice quickly, and there are no messages sent between the calls, you get 0.

Time Last Update
-----------------------
This value represents the last time statistics where calculated by the messaging system. It is fired off of a timer, so the message count can be zero and it will still update

> Make sure that the metrics for Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as ViewUse.STATISTIC
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6720
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6720
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: JBoss AS Branch_5_x r86586, embjopr r266
> EmbJopr TS: testQueueMetrics
>            Reporter: Farah Juma
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Steps to reproduce:
> Create a new Topic or Queue using Embedded Jopr. Send some messages to the Topic or Queue. Navigate to the "Metrics" tab for the resource. The metrics do not get updated to reflect this change. All the values are 0.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:09:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7038) Track component
 update - 5.2.0.Beta1
In-Reply-To: <2791010.1245334316593.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30668441.1245474596428.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene reassigned JBAS-7038:
-------------------------------------

    Assignee: Jason T. Greene


> Track component update - 5.2.0.Beta1
> ------------------------------------
>
>                 Key: JBAS-7038
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7038
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Jason T. Greene
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:11:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7040) Update MDR to
	2.0.2.GA
In-Reply-To: <15426592.1245474716667.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14745418.1245474716825.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBAS-7040:
----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> Update MDR to 2.0.2.GA
> ----------------------
>
>                 Key: JBAS-7040
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7040
>             Project: JBoss Application Server
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: MicroContainer bus
>            Reporter: Jason T. Greene
>            Assignee: Ales Justin
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:11:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7040) Update MDR to
	2.0.2.GA
Message-ID: <15426592.1245474716667.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update MDR to 2.0.2.GA
----------------------

                 Key: JBAS-7040
                 URL: https://jira.jboss.org/jira/browse/JBAS-7040
             Project: JBoss Application Server
          Issue Type: Component Upgrade
      Security Level: Public (Everyone can see)
          Components: MicroContainer bus
            Reporter: Jason T. Greene
            Assignee: Ales Justin




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:11:57 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:11:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7042) Update Deployers to
	2.0.8.GA
Message-ID: <3578800.1245474717340.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update Deployers to 2.0.8.GA
----------------------------

                 Key: JBAS-7042
                 URL: https://jira.jboss.org/jira/browse/JBAS-7042
             Project: JBoss Application Server
          Issue Type: Component Upgrade
      Security Level: Public (Everyone can see)
          Components: MicroContainer bus
            Reporter: Jason T. Greene
            Assignee: Ales Justin
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:11:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7040) Update MDR to 2.0.2.GA
In-Reply-To: <15426592.1245474716667.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6629930.1245474717000.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene closed JBAS-7040.
---------------------------------

    Resolution: Done


> Update MDR to 2.0.2.GA
> ----------------------
>
>                 Key: JBAS-7040
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7040
>             Project: JBoss Application Server
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: MicroContainer bus
>            Reporter: Jason T. Greene
>            Assignee: Ales Justin
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:14:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7042) Update Deployers to
	2.0.8.GA
In-Reply-To: <3578800.1245474717340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19341480.1245474896767.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene closed JBAS-7042.
---------------------------------

    Resolution: Done


> Update Deployers to 2.0.8.GA
> ----------------------------
>
>                 Key: JBAS-7042
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7042
>             Project: JBoss Application Server
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: MicroContainer bus
>            Reporter: Jason T. Greene
>            Assignee: Ales Justin
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:14:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7041) Update Kernel to
	2.0.7.GA
In-Reply-To: <31182505.1245474717156.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30861784.1245474896594.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene closed JBAS-7041.
---------------------------------

    Resolution: Done


> Update Kernel to 2.0.7.GA
> -------------------------
>
>                 Key: JBAS-7041
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7041
>             Project: JBoss Application Server
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: MicroContainer bus
>            Reporter: Jason T. Greene
>            Assignee: Ales Justin
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:11:57 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:11:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7041) Update Kernel to
	2.0.7.GA
Message-ID: <31182505.1245474717156.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update Kernel to 2.0.7.GA
-------------------------

                 Key: JBAS-7041
                 URL: https://jira.jboss.org/jira/browse/JBAS-7041
             Project: JBoss Application Server
          Issue Type: Component Upgrade
      Security Level: Public (Everyone can see)
          Components: MicroContainer bus
            Reporter: Jason T. Greene
            Assignee: Ales Justin
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:59:08 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:59:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS Topics
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16213372.1245477548631.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBAS-6783:
----------------------------------

        Summary: NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics  (was: NPE when setting 'messageCounterHistoryDayLimit' prop on JMS destinations)
    Component/s: JMS (JBoss Messaging)
                     (was: ProfileService)
    Description: 
Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:

Caused by: java.lang.NullPointerException
	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)

Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .

The problem is that the property is only expected to be set at runtime, AFTER the topic has started:

 Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);




  was:
Reporting this on behalf of Emanuel.


See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 for his original comments.
In todays meeting he mentioned you get an NPE when setting the messageCounterHistoryDayLimit  property.


More investigation is needed.



> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics
> -------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:
> Caused by: java.lang.NullPointerException
> 	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
> 	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)
> Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .
> The problem is that the property is only expected to be set at runtime, AFTER the topic has started:
>  Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 01:59:08 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 01:59:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS Topics
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25004208.1245477548954.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene reassigned JBAS-6783:
-------------------------------------

    Assignee: Howard Gao  (was: Jason T. Greene)


> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics
> -------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Howard Gao
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:
> Caused by: java.lang.NullPointerException
> 	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
> 	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)
> Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .
> The problem is that the property is only expected to be set at runtime, AFTER the topic has started:
>  Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 02:00:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 02:00:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS Topics
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16346419.1245477656602.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBAS-6783:
----------------------------------

    Description: 
Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:

<attribute name="MessageCounterHistoryDayLimit">10</attribute>

Caused by: java.lang.NullPointerException
	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)

Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .

The problem is that the property is only expected to be set at runtime, AFTER the topic has started:

 Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);




  was:
Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:

Caused by: java.lang.NullPointerException
	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)

Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .

The problem is that the property is only expected to be set at runtime, AFTER the topic has started:

 Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);






> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics
> -------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Howard Gao
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:
> <attribute name="MessageCounterHistoryDayLimit">10</attribute>
> Caused by: java.lang.NullPointerException
> 	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
> 	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)
> Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .
> The problem is that the property is only expected to be set at runtime, AFTER the topic has started:
>  Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 02:02:56 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sat, 20 Jun 2009 02:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS Topics
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9319609.1245477776576.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473113#action_12473113 ] 

Jason T. Greene commented on JBAS-6783:
---------------------------------------

The fix should be to change the setMessageCounterHistoryDayLimit to not update the counters if they don't exist yet (serverPeer doesn't exist yet)

> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics
> -------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Howard Gao
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:
> <attribute name="MessageCounterHistoryDayLimit">10</attribute>
> Caused by: java.lang.NullPointerException
> 	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
> 	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)
> Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .
> The problem is that the property is only expected to be set at runtime, AFTER the topic has started:
>  Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 12:48:18 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Sat, 20 Jun 2009 12:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1663) Release JBoss
 Messaging 2.0.0.Beta3
Message-ID: <27353572.1245516498941.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release JBoss Messaging 2.0.0.Beta3
-----------------------------------

                 Key: JBMESSAGING-1663
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1663
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Clebert Suconic
            Assignee: Clebert Suconic




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 17:11:04 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Sat, 20 Jun 2009 17:11:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1663) Release JBoss
 Messaging 2.0.0.Beta3
In-Reply-To: <27353572.1245516498941.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10772870.1245532266035.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1663:
-----------------------------------------

    Attachment: messaging-2.0.0.BETA3-noDocs.zip


> Release JBoss Messaging 2.0.0.Beta3
> -----------------------------------
>
>                 Key: JBMESSAGING-1663
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1663
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>         Attachments: messaging-2.0.0.BETA3-noDocs.zip
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 22:42:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Sat, 20 Jun 2009 22:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1663) Release JBoss
 Messaging 2.0.0.Beta3
In-Reply-To: <27353572.1245516498941.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11979459.1245552176755.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1663:
-----------------------------------------

    Attachment:     (was: messaging-2.0.0.BETA3-noDocs.zip)


> Release JBoss Messaging 2.0.0.Beta3
> -----------------------------------
>
>                 Key: JBMESSAGING-1663
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1663
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 22:44:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Sat, 20 Jun 2009 22:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1663) Release JBoss
 Messaging 2.0.0.Beta3
In-Reply-To: <27353572.1245516498941.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15619414.1245552296797.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1663:
-----------------------------------------

    Attachment: messaging-2


> Release JBoss Messaging 2.0.0.Beta3
> -----------------------------------
>
>                 Key: JBMESSAGING-1663
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1663
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>         Attachments: messaging-1, messaging-2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 20 22:44:56 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Sat, 20 Jun 2009 22:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1663) Release JBoss
 Messaging 2.0.0.Beta3
In-Reply-To: <27353572.1245516498941.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32104892.1245552296539.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1663:
-----------------------------------------

    Attachment: messaging-1


> Release JBoss Messaging 2.0.0.Beta3
> -----------------------------------
>
>                 Key: JBMESSAGING-1663
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1663
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>         Attachments: messaging-1, messaging-2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 13:52:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Sun, 21 Jun 2009 13:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7043) /docs/schema does
 not contain bean-deployer xsds
Message-ID: <2403334.1245606776409.JavaMail.jira@cloud.prod.atl2.jboss.com>

/docs/schema does not contain bean-deployer xsds
------------------------------------------------

                 Key: JBAS-7043
                 URL: https://jira.jboss.org/jira/browse/JBAS-7043
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Wolfgang Knauf


The microcontainer related schema definitions can currently be found only in "lib\jboss-kernel.jar", but they should also be placed in "docs\schema" in the JBoss installation like all the other schema definitions.

The files are:
-bean-deployer_1_0.xsd
-bean-deployer_2_0.xsd
-jboss-beans-common_2_0.xsd
-policy_1_0.xsd

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 13:27:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Sun, 21 Jun 2009 13:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMICROCONT-446) bean-deployer
 xsds don't contain web references
Message-ID: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>

bean-deployer xsds don't contain web references
-----------------------------------------------

                 Key: JBMICROCONT-446
                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
             Project: JBoss Microcontainer
          Issue Type: Bug
            Reporter: Wolfgang Knauf


bean-deployer_2_0.xsd:

   <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">

=>should point. 
   <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">

The comment for a sample instance should also contain a schema location attribute:
         <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns="urn:jboss:bean-deployer:2.0"
            xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">

==================
bean-deployer_1_0.xsd:

The comment for a sample instance should point to the web schema location:
         <deployment
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
            xmlns="urn:jboss:bean-deployer">

=================
policy_1_0.xsd:
   <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
should be:
   <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>

=================
bean-deployer_2_0.xsd raises validation errors in Eclipse:
-rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
-src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 13:29:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Sun, 21 Jun 2009 13:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMICROCONT-446) bean-deployer
 xsds don't contain web references
In-Reply-To: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9752426.1245605396430.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMICROCONT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolfgang Knauf updated JBMICROCONT-446:
---------------------------------------

    Description: 
bean-deployer_2_0.xsd:

   <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">

=>should point. 
   <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">

The comment for a sample instance should also contain a schema location attribute:
         <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns="urn:jboss:bean-deployer:2.0"
            xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">

==================
bean-deployer_1_0.xsd:

The comment for a sample instance should point to the web schema location:
         <deployment
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
            xmlns="urn:jboss:bean-deployer">

=================
policy_1_0.xsd:
   <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
should be:
   <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>

=================
bean-deployer_2_0.xsd raises validation errors in Eclipse:
-rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
-src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

  was:
bean-deployer_2_0.xsd:

   <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">

=>should point. 
   <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">

The comment for a sample instance should also contain a schema location attribute:
         <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns="urn:jboss:bean-deployer:2.0"
            xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">

==================
bean-deployer_1_0.xsd:

The comment for a sample instance should point to the web schema location:
         <deployment
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
            xmlns="urn:jboss:bean-deployer">

=================
policy_1_0.xsd:
   <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
should be:
   <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>

=================
bean-deployer_2_0.xsd raises validation errors in Eclipse:
-rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
-src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.



> bean-deployer xsds don't contain web references
> -----------------------------------------------
>
>                 Key: JBMICROCONT-446
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Wolfgang Knauf
>
> bean-deployer_2_0.xsd:
>    <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
> =>should point. 
>    <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">
> The comment for a sample instance should also contain a schema location attribute:
>          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xmlns="urn:jboss:bean-deployer:2.0"
>             xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">
> ==================
> bean-deployer_1_0.xsd:
> The comment for a sample instance should point to the web schema location:
>          <deployment
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
>             xmlns="urn:jboss:bean-deployer">
> =================
> policy_1_0.xsd:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
> should be:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>
> =================
> bean-deployer_2_0.xsd raises validation errors in Eclipse:
> -rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
> -src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
> According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 13:31:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Sun, 21 Jun 2009 13:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7034) Outdated/missing
 schema files on website
In-Reply-To: <15960137.1245267836412.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27261627.1245605516432.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolfgang Knauf updated JBAS-7034:
---------------------------------

    Description: 
Some xsd files are missing or are outdated at http://www.jboss.org/j2ee/schema/

Please update from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/):

jboss-ds_5_0.xsd (missing)
jboss-web_5_1.xsd (missing)
jboss_common_5_1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.0.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-185 )
(some still do not validate because of invalid schema locations, so they must be updated again if https://jira.jboss.org/jira/browse/JBMETA-210 is fixed)

bean-deployer_1_0.xsd (missing)
bean-deployer_2_0.xsd (missing)
jboss-beans-common_2_0.xsd (missing)
policy_1_0.xsd (missing)
Note: they do not validate, too (invalid schema locations, and a (maybe false) validation error, see https://jira.jboss.org/jira/browse/JBMICROCONT-446 ), but they should be available on the website anyway.

  was:
Some xsd files are missing or are outdated at http://www.jboss.org/j2ee/schema/

Please update from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/):

jboss-ds_5_0.xsd (missing)
jboss-web_5_1.xsd (missing)
jboss_common_5_1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.0.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-185 )
(some still do not validate because of invalid schema locations, so they must be updated again if https://jira.jboss.org/jira/browse/JBMETA-210 is fixed)

bean-deployer_1_0.xsd (missing)
bean-deployer_2_0.xsd (missing)
jboss-beans-common_2_0.xsd (missing)
policy_1_0.xsd (missing)
Note: they do not validate, too (invalid schema locations, and a (maybe false) validation error), but they should be available on the website anyway.



> Outdated/missing schema files on website
> ----------------------------------------
>
>                 Key: JBAS-7034
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7034
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Wolfgang Knauf
>
> Some xsd files are missing or are outdated at http://www.jboss.org/j2ee/schema/
> Please update from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/):
> jboss-ds_5_0.xsd (missing)
> jboss-web_5_1.xsd (missing)
> jboss_common_5_1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
> jboss_5.1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
> jboss_5.0.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-185 )
> (some still do not validate because of invalid schema locations, so they must be updated again if https://jira.jboss.org/jira/browse/JBMETA-210 is fixed)
> bean-deployer_1_0.xsd (missing)
> bean-deployer_2_0.xsd (missing)
> jboss-beans-common_2_0.xsd (missing)
> policy_1_0.xsd (missing)
> Note: they do not validate, too (invalid schema locations, and a (maybe false) validation error, see https://jira.jboss.org/jira/browse/JBMICROCONT-446 ), but they should be available on the website anyway.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 17:07:07 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Sun, 21 Jun 2009 17:07:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-737) Duplicate bind
 element at injboss example
In-Reply-To: <29249137.1245618296598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13647544.1245618427013.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAOP-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473169#action_12473169 ] 

Flavia Rainone commented on JBAOP-737:
--------------------------------------

Thanks to Luciano Malagris for pointing this out :-)

> Duplicate bind element at injboss example
> -----------------------------------------
>
>                 Key: JBAOP-737
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-737
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>             Fix For: 2.1.2.GA
>
>
> There is a duplicate entry of the bind element at the jboss-aop.xml file of the injboss example (tutorial):
> http://www.jboss.org/jbossaop/docs/2.0.0.GA/docs/aspect-framework/examples/injboss/aopInJbossPackaging.html
> This needs to be fixed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 17:04:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Sun, 21 Jun 2009 17:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-737) Duplicate bind
 element at injboss example
Message-ID: <29249137.1245618296598.JavaMail.jira@cloud.prod.atl2.jboss.com>

Duplicate bind element at injboss example
-----------------------------------------

                 Key: JBAOP-737
                 URL: https://jira.jboss.org/jira/browse/JBAOP-737
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.1.GA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: 2.1.2.GA


There is a duplicate entry of the bind element at the jboss-aop.xml file of the injboss example (tutorial):
http://www.jboss.org/jbossaop/docs/2.0.0.GA/docs/aspect-framework/examples/injboss/aopInJbossPackaging.html

This needs to be fixed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 19:50:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Sun, 21 Jun 2009 19:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-738) Error for overloaded
 methods with Invocations and Joinpoint
Message-ID: <11375593.1245628256421.JavaMail.jira@cloud.prod.atl2.jboss.com>

Error for overloaded methods with Invocations and Joinpoint
-----------------------------------------------------------

                 Key: JBAOP-738
                 URL: https://jira.jboss.org/jira/browse/JBAOP-738
             Project: JBoss AOP
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.1.GA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone


JBoss AOP gets confused when, for a typed advice that not around, the advice method is overloaded and there is a version that receives an Invocation. So, for the example below:

public Object adendo(@JoinPoint MethodInvocation invocation,
			@Args Object[] args)
	throws Throwable {...}
	
       
public void adendo(@JoinPoint MethodExecution joinpoint,
			@Args Object[] args)
	throws Throwable {...}

JBoss AOP will complain of the version with Invocation, stating it is inappropriate for an advice of type before/after/whatever, while it should be able of finding the version that gets a MethodExecution and bind that version of " adendo" method.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 21:32:57 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Sun, 21 Jun 2009 21:32:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6449)
 InvokerAdaptorService
 overwrites existing SecurityContext and clears it after invocation
In-Reply-To: <20893098.1233747464875.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9795822.1245634377075.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473173#action_12473173 ] 

Richard Kennard commented on JBAS-6449:
---------------------------------------

Confirming this bug still in 5.1.0.GA. It's very bad, as it makes it next to impossible to, say, check the depth of a queue...

RMIAdaptor server = (RMIAdaptor) new InitialContext().lookup( EjbUtils.lookupEnv( "core/jmx-connection" ) );
ObjectName objectName = new ObjectName( "jboss.messaging.destination:service=Queue,name=" + queue );
int queueDepth = 0;(Integer) server.getAttribute( objectName, "MessageCount" );

...this code works, but subsequent calls to EJBs all fail because the last line (server.getAttribute) clears the security context.

Is there a workaround?

> InvokerAdaptorService overwrites existing SecurityContext and clears it after invocation
> ----------------------------------------------------------------------------------------
>
>                 Key: JBAS-6449
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6449
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows Vista, JBoss 5.0.0 GA
>            Reporter: Michael Gronau
>
> The InvokerAdaptorService always creates a new SecurityContext even if there is already one created by components called earlier in invocation stack. After invoking the desired MBean method the SecurityContext will be cleared with a call to: SecurityActions.clearSecurityContext();
> This leads to several problems:
> In our project we have a secured EJB (annotated with @SecurityDomain) which is calling an MBean Service and a local (secured) EJB. After the invocation of the mbean there is no security context anymore which leads to an IllegalStateException "Security Context has not been set" thrown by RoleBasedAuthorizationInterceptorv2) when we try to call the local EJB.
> Following steps are possible to fix the problem:
> 1. call to SecurityActions.getSecurityContext();
> 2. if there is currently no SecurityContext create a new one and set it.
> 3. if there already is a SecurityContext set, do nothing.
> 4. call the mbean method.
> 5. only if we created the SecurityContext, we should clear it with SecurityActions.clearSecurityContext(), otherwise, do nothing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 21 21:36:56 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Sun, 21 Jun 2009 21:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6449)
 InvokerAdaptorService
 overwrites existing SecurityContext and clears it after invocation
In-Reply-To: <20893098.1233747464875.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19738061.1245634616900.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473174#action_12473174 ] 

Richard Kennard commented on JBAS-6449:
---------------------------------------

I should further mention this problem was not present in JBoss 4.2.3.GA. The above code worked without problem (albeit using 'jboss.mq.destination.service' and 'QueueDepth')

> InvokerAdaptorService overwrites existing SecurityContext and clears it after invocation
> ----------------------------------------------------------------------------------------
>
>                 Key: JBAS-6449
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6449
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows Vista, JBoss 5.0.0 GA
>            Reporter: Michael Gronau
>
> The InvokerAdaptorService always creates a new SecurityContext even if there is already one created by components called earlier in invocation stack. After invoking the desired MBean method the SecurityContext will be cleared with a call to: SecurityActions.clearSecurityContext();
> This leads to several problems:
> In our project we have a secured EJB (annotated with @SecurityDomain) which is calling an MBean Service and a local (secured) EJB. After the invocation of the mbean there is no security context anymore which leads to an IllegalStateException "Security Context has not been set" thrown by RoleBasedAuthorizationInterceptorv2) when we try to call the local EJB.
> Following steps are possible to fix the problem:
> 1. call to SecurityActions.getSecurityContext();
> 2. if there is currently no SecurityContext create a new one and set it.
> 3. if there already is a SecurityContext set, do nothing.
> 4. call the mbean method.
> 5. only if we created the SecurityContext, we should clear it with SecurityActions.clearSecurityContext(), otherwise, do nothing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 02:32:57 2009
From: jira-events at lists.jboss.org (Osamu Yokomizo (JIRA))
Date: Mon, 22 Jun 2009 02:32:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32107598.1245652377163.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Osamu Yokomizo updated EJBTHREE-995:
------------------------------------

    Attachment: src.zip


This is source files.

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>         Attachments: src.zip
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 02:34:56 2009
From: jira-events at lists.jboss.org (Osamu Yokomizo (JIRA))
Date: Mon, 22 Jun 2009 02:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10921708.1245652496631.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Osamu Yokomizo updated EJBTHREE-995:
------------------------------------

    Attachment: sample.jar


This is jar(EJB and Client)

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>         Attachments: sample.jar, src.zip
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 03:36:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 22 Jun 2009 03:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1664) Ordering
 Group is broken
 on server restart when messages are paged and reloaded
Message-ID: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ordering Group is broken on server restart when messages are paged and reloaded
-------------------------------------------------------------------------------

                 Key: JBMESSAGING-1664
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.4.GA, 1.4.0.SP3.CP08
            Reporter: Howard Gao
            Assignee: Howard Gao
             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA


When messages are paged into the DB and reloaded on server restart, the strict is broken.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 03:50:57 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 22 Jun 2009 03:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2133) Drools-solver
 manual corrections from Yet another math programming consultant blog
Message-ID: <15744621.1245657057041.JavaMail.jira@cloud.prod.atl2.jboss.com>

Drools-solver manual corrections from Yet another math programming consultant blog
----------------------------------------------------------------------------------

                 Key: JBRULES-2133
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2133
             Project: JBoss Drools
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: drools-solver
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet
            Priority: Optional


http://yetanothermathprogrammingconsultant.blogspot.com/2009/06/simplex-method-description.html?showComment=1245656649020#c9186233704679009828

- The branch&bound section should mention about the unique feature that it provides bounds and hence an indication of the quality of the solution.

- The simplex  section is supposedly wrong (It's unclear how it can be corrected): "If the word Simplex was missing I would not recognize this is about the Simplex method. One big equation? (No word about not being suited to handle discrete variables)."

- "Local search starts from an initial solution and evolves that single solution into a better and better solution." should be "Local search starts from an initial solution and evolves that single solution, ussually into a better and better solution."


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 03:54:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 22 Jun 2009 03:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2133) Drools-solver
 manual corrections from Yet another math programming consultant blog
In-Reply-To: <15744621.1245657057041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <230969.1245657296531.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473218#action_12473218 ] 

Geoffrey De Smet commented on JBRULES-2133:
-------------------------------------------

If no correction on the simplex section is given, I 'll probably remove it for now.

> Drools-solver manual corrections from Yet another math programming consultant blog
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2133
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2133
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Optional
>
> http://yetanothermathprogrammingconsultant.blogspot.com/2009/06/simplex-method-description.html?showComment=1245656649020#c9186233704679009828
> - The branch&bound section should mention about the unique feature that it provides bounds and hence an indication of the quality of the solution.
> - The simplex  section is supposedly wrong (It's unclear how it can be corrected): "If the word Simplex was missing I would not recognize this is about the Simplex method. One big equation? (No word about not being suited to handle discrete variables)."
> - "Local search starts from an initial solution and evolves that single solution into a better and better solution." should be "Local search starts from an initial solution and evolves that single solution, ussually into a better and better solution."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 02:32:56 2009
From: jira-events at lists.jboss.org (Osamu Yokomizo (JIRA))
Date: Mon, 22 Jun 2009 02:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5617215.1245652376937.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473193#action_12473193 ] 

Osamu Yokomizo commented on EJBTHREE-995:
-----------------------------------------

Hi , Andrew.

The reproduced program was put, and look, please.

1: deploy sample.jar
2: execute client SampleClient.
   SampleClient is in sample.jar. 

This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

server.log
====
...
15:05:36,406 INFO  [Server] JBoss (MX MicroKernel) [4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181439)] Started in 11s:891ms
15:06:00,859 INFO  [STDOUT] ut.begin():6
15:06:00,859 INFO  [STDOUT] afterBegin()
15:06:00,875 INFO  [STDOUT] afterBegin()
15:06:00,875 INFO  [STDOUT] afterBegin()
15:06:00,875 INFO  [STDOUT] beforeCompletion():
15:06:00,875 INFO  [STDOUT] beforeCompletion():
15:06:00,875 INFO  [STDOUT] beforeCompletion():
15:06:00,875 INFO  [STDOUT] afterCompletion():true
15:06:00,875 INFO  [STDOUT] afterCompletion():true
15:06:00,875 INFO  [STDOUT] afterCompletion():true
====


> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>         Attachments: src.zip
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 04:45:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 22 Jun 2009 04:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1639) Validate
 configuration values programmatically
In-Reply-To: <9257056.1244133116418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8077793.1245660356855.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1639.
------------------------------------

    Fix Version/s: 2.0.0.beta3
                       (was: 2.0.0)
       Resolution: Done


fixed in the trunk

> Validate configuration values programmatically
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1639
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1639
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0.beta3
>
>
> using XSD to validate configuration values make the schema more complex and error-prone (the error messages are hard to understand too).
> We should move to programmatic validation. E.g. in FileConfiguration, when we read the values from the configuration, we could add a validation step to check values (e.g. must be -1 or > 0 which is impossible to express in a XML Schema)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 03:01:07 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 22 Jun 2009 03:01:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11905023.1245654067523.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473197#action_12473197 ] 

Andrew Lee Rubinger commented on EJBTHREE-995:
----------------------------------------------

Thanks for the attachments, Osamu.  We've been looking for a failing case.  I'll see if I can port these to reproduce in AS 5.x as well.

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>         Attachments: sample.jar, src.zip
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 05:28:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 22 Jun 2009 05:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2134) Configure a custom
 termination, selector, accepter or forager: document how to in the manual
Message-ID: <3915765.1245662936924.JavaMail.jira@cloud.prod.atl2.jboss.com>

Configure a custom termination, selector, accepter or forager: document how to in the manual
--------------------------------------------------------------------------------------------

                 Key: JBRULES-2134
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2134
             Project: JBoss Drools
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: drools-solver
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet
            Priority: Minor


Is it possible?
I think it should be possible by writing your own MyAccepterConfig next to your own MyAccepter.
One of the examples should show how this works and the manual should show it too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 05:30:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 22 Jun 2009 05:30:56 -0400 (EDT)
Subject: [jboss-jira] 
 [JBoss JIRA] Commented: (JBRULES-1328) SelectorConfig, 
 AccepterConfig en other Config's aren't Serializable
 if they have a direct Selector/Accepter instance configured
In-Reply-To: <17195507.1195227678726.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9769564.1245663056570.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473228#action_12473228 ] 

Geoffrey De Smet commented on JBRULES-1328:
-------------------------------------------

JBRULES-2134 will provide a better solution and the ability to put in a accepter in AccepterConfig etc should be removed

> SelectorConfig, AccepterConfig en other Config's aren't Serializable if they have a direct Selector/Accepter instance configured
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1328
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1328
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Optional
>
> Because AbstractAccepter references LocalSearchSolver references the drools RuleBase references stuff that isn't Serializable...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 08:47:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 22 Jun 2009 08:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1664) Ordering Group
 is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14023424.1245674876482.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1664.
-----------------------------------

    Resolution: Done


done

> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:05:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 22 Jun 2009 09:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1437) Browsers
 should iterate on queue
In-Reply-To: <33355941.1225819521109.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4560232.1245675956725.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1437:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Browsers should iterate on queue
> --------------------------------
>
>                 Key: JBMESSAGING-1437
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1437
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>         Attachments: patch-JBMESSAGING-1437.txt
>
>
> Currently the server browser implementation is taking a snapshot of the queue and browsing that. Instead we should implement an iterator on the queue which allows refs to be added or removed from the ends without affecting it.
> This is also necessary to allow failover for browsers which is very hard to implement with the current snapshot approach

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:34:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 22 Jun 2009 09:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-999) Remove deprecated
 classes or methods
Message-ID: <9740032.1245677696663.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remove deprecated classes or methods
------------------------------------

                 Key: JGRP-999
                 URL: https://jira.jboss.org/jira/browse/JGRP-999
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.0


Classes/methods annotated with @Deprecated (or @deprecated in the Javadocs) need to be removed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:26:10 2009
From: jira-events at lists.jboss.org (Juergen W (JIRA))
Date: Mon, 22 Jun 2009 09:26:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-115) Bug in
 AbstractEntityPersister for generated version properties
Message-ID: <24166695.1245677170570.JavaMail.jira@cloud.prod.atl2.jboss.com>

Bug in AbstractEntityPersister for generated version properties
---------------------------------------------------------------

                 Key: HIBERNATE-115
                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-115
             Project: Hibernate
          Issue Type: Bug
         Environment: Jboss 4.2.3 GA, Hibernate 3.3.1, MSSQL Server 2005, actual Merlia DB Driver 7.0.5
            Reporter: Juergen W
            Assignee: Steve Ebersole


Following problem:

we're using following configuration for our entities (dynamic-update="true" , dynamic-insert="true" , select-before-update="true", the version property is generated by the database and is read-only )

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping>
<class name="de.xxx.xxx.Angebot"  
   table="ANGeBot" 
   dynamic-update="true"  
   dynamic-insert="true" 
   select-before-update="true">
 
<id name="angbId" type="java.lang.Integer" column="ANGB_ID" unsaved-value="0">
	<generator class="identity"/>
</id>
     <version name="Timestamp" type="binary" column="ANGB_Timestamp" generated="always" insert="false" unsaved-value="undefined"/>  

	<property name="Aenderungsdatum" column="ANGB_Aenderungsdatum" type="java.util.Date" length="23"/>
	<property name="Aenderungsperson" column="ANGB_Aenderungsperson" type="java.lang.String" length="30"/>
	<property name="AnbieterAnsprechpartner" column="ANGB_Anbieter_Ansprechpartner" type="java.lang.String" length="100"/>

       ... additional props...
</class>
</hibernate-mapping>


If we made some changes to a row, hibernate should update only the "dirty fields" and NOT the version field. But hibernate tries to update the version property too, and thus we got the  db exception, the version column is not updateable.

Hibernate generates following updatestatement, if we change the field ANGB_ANBIETER_ANSPRECHPARTNER

 UPDATE
            V_AMVW_ANGEBOT
        SET
            ANGB_TIMESTAMP=?,    <----  THATs WRONG
            ANGB_ANBIETER_ANSPRECHPARTNER=?
        WHERE
            ANGB_ID=?
            AND ANGB_TIMESTAMP=?


I think, in the org.hibernate.persister.entity.AbstractEntityPersister in the method getPropertiesToUpdate() following "if statement" is missing if the version property is generated:

		if ( isVersioned()) {
			propsToUpdate[ getVersionProperty() ] =
				Versioning.isVersionIncrementRequired( dirtyProperties, hasDirtyCollection, getPropertyVersionability() );
		}


If I change the "if" statement to following:

		if ( isVersioned() && !isVersionPropertyGenerated()) {
			propsToUpdate[ getVersionProperty() ] =
				Versioning.isVersionIncrementRequired( dirtyProperties, hasDirtyCollection, getPropertyVersionability() );
		}

than it is working


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:04:10 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 22 Jun 2009 09:04:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1437) Browsers
 should iterate on queue
In-Reply-To: <33355941.1225819521109.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2504761.1245675850036.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated JBMESSAGING-1437:
-------------------------------------

    Attachment: patch-JBMESSAGING-1437.txt


A patch to have a "browser" consumer iterates directly on the queue rather than create a snapshot copy of it.

This code does not work when browsing a queue with large messages

> Browsers should iterate on queue
> --------------------------------
>
>                 Key: JBMESSAGING-1437
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1437
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>         Attachments: patch-JBMESSAGING-1437.txt
>
>
> Currently the server browser implementation is taking a snapshot of the queue and browsing that. Instead we should implement an iterator on the queue which allows refs to be added or removed from the ends without affecting it.
> This is also necessary to allow failover for browsers which is very hard to implement with the current snapshot approach

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:19:56 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Mon, 22 Jun 2009 09:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-739)
 NoMatchingAdviceException does not list @Joinpoint Parameters
Message-ID: <29353533.1245676796603.JavaMail.jira@cloud.prod.atl2.jboss.com>

NoMatchingAdviceException does not list @Joinpoint Parameters
-------------------------------------------------------------

                 Key: JBAOP-739
                 URL: https://jira.jboss.org/jira/browse/JBAOP-739
             Project: JBoss AOP
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.2.GA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: 2.2.0.GA


When using a before advice to intercept a void method execution, if the before advice has the wrong signature, JBoss AOP thrown a NoMatchingAdviceException stating that it would only accept @Arg and @Args parameters.
This exception's message should also list the possibility of using @JoinPoint parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 08:43:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 22 Jun 2009 08:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken
 on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10233010.1245674636560.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473242#action_12473242 ] 

Howard Gao commented on JBMESSAGING-1664:
-----------------------------------------

The reason why it doesn't work in case of paging is that when the server is restarted and start delivering messages, paged messages will be loaded from the DB and put to the queue. And the ordering group doesn't handle this case.
To fix it, we need to add the control during the loading of paged messages in PagingChannelSupport.loadPagedReferences():

...
      while (iter.hasNext())
      {
         ReferenceInfo info = (ReferenceInfo)iter.next();
         
         MessageReference ref = addFromRefInfo(info, refMap);
         
         monitor.registerMessage(ref);  ---------------this adds the message to the ordering group control.
...



> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 10:48:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 22 Jun 2009 10:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24984971.1245682136735.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1852:
--------------------------------------

    Assignee: jaikiran pai


> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: jaikiran pai
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:00:04 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Mon, 22 Jun 2009 09:00:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1652) Convert build
 to use Maven repository
In-Reply-To: <20391798.1244809196438.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25249373.1245675604689.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1652.
------------------------------------

    Resolution: Done


> Convert build to use Maven repository
> -------------------------------------
>
>                 Key: JBMESSAGING-1652
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1652
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> We should convert the build to use the Maven repository and Maven dependency checking rather than the old JBoss Repository.
> The rest of the build can stay with ant.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:55:57 2009
From: jira-events at lists.jboss.org (Jonathon Leibundguth (JIRA))
Date: Mon, 22 Jun 2009 09:55:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2135) Deadlock occurs
 in
 Multithreaded Environment NamedEntryPoint lock and AbstractWorkingMemory
 actionQueue sync block.
In-Reply-To: <28635049.1245678836810.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1344925.1245678958007.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473255#action_12473255 ] 

Jonathon Leibundguth commented on JBRULES-2135:
-----------------------------------------------

I believe something like this replaced method for AbstractWorkingMemory may resolve the issue, but I am not fully versed in the Drools Core code (pls don't kill me) - also this was a quick fix to unblock our project, there may be a more elegant impl., but point is to either move the execute() action outside of the sync block or find another avenue to resolve deadlock between actionQueue locking and NamedEntryPoint Reentrant lock:

    public void executeQueuedActions() {
    	// fill this so that execute is called outside of the sync block to avoid deadlock
    	Queue<WorkingMemoryAction> execQueue = new LinkedList<WorkingMemoryAction>();

    	synchronized ( this.actionQueue ) {
            if ( !this.actionQueue.isEmpty() && !evaluatingActionQueue ) {
                evaluatingActionQueue = true;
                WorkingMemoryAction action = null;
                while ( (action = actionQueue.poll()) != null ) {
                	execQueue.add(action);
                }
                evaluatingActionQueue = false;
            }
        }
        WorkingMemoryAction execAction = null;
        while ( (execAction = execQueue.poll()) != null ) {
            try {
            	execAction.execute( this );
            } catch ( Exception e ) {
                if( e instanceof RuntimeDroolsException ) {
                    // rethrow the exception
                    throw ((RuntimeDroolsException)e);
                } else {
                    System.err.println("************************************************");
                    System.err.println("Exception caught while executing action: "+execAction.toString());
                    e.printStackTrace();
                }
            }
        }
    	
    }

> Deadlock occurs in Multithreaded Environment NamedEntryPoint lock and AbstractWorkingMemory actionQueue sync block.
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2135
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2135
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.0.1.FINAL
>         Environment: java version "1.6.0_0"
> OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu7)
> OpenJDK Client VM (build 14.0-b08, mixed mode, sharing)
>            Reporter: Jonathon Leibundguth
>            Assignee: Mark Proctor
>            Priority: Critical
>
> While running drools using fireUntilHalt in multithreaded environment, the following situation results in deadlock:
> Thread A (Drools' Thread):  AbstractWorkingMemory method executeQueuedActions() locks actionQueue:
> synchronized ( this.actionQueue )
> Calls action.execute( this ) for each item in queue, in this case WorkingMemoryReteExpireAction to expire an event object.  The  WorkingMemoryReteExpireAction tries to obtain the lock in NamedEntryPoint during call to retract().
> Thread B (User's Thread):  attempts to execute a NamedEntryPoint insert() action simultaneously with the above.  The thread obtains the NamedEntryPoint lock and blocks waiting for the lock on actionQueue.
> Deadlock:
> Thread A is blocked waiting for NamedEntryPoint lock, owned by Thread B.
> Thread B is blocked waiting for lock on actionQueue, owned by Thread A.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:15:07 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Mon, 22 Jun 2009 09:15:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1612) Provide a
 complete JCA Parmeters override
In-Reply-To: <23605475.1241104013618.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9338040.1245676507366.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor reassigned JBMESSAGING-1612:
----------------------------------------

    Assignee: Andy Taylor  (was: Clebert Suconic)


> Provide a complete JCA Parmeters override
> -----------------------------------------
>
>                 Key: JBMESSAGING-1612
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1612
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:53:56 2009
From: jira-events at lists.jboss.org (Jonathon Leibundguth (JIRA))
Date: Mon, 22 Jun 2009 09:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2135) Deadlock occurs in
 Multithreaded Environment NamedEntryPoint lock and AbstractWorkingMemory
 actionQueue sync block.
Message-ID: <28635049.1245678836810.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deadlock occurs in Multithreaded Environment NamedEntryPoint lock and AbstractWorkingMemory actionQueue sync block.
-------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2135
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2135
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core (fusion)
    Affects Versions: 5.0.1.FINAL
         Environment: java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu7)
OpenJDK Client VM (build 14.0-b08, mixed mode, sharing)
            Reporter: Jonathon Leibundguth
            Assignee: Mark Proctor
            Priority: Critical


While running drools using fireUntilHalt in multithreaded environment, the following situation results in deadlock:

Thread A (Drools' Thread):  AbstractWorkingMemory method executeQueuedActions() locks actionQueue:

synchronized ( this.actionQueue )

Calls action.execute( this ) for each item in queue, in this case WorkingMemoryReteExpireAction to expire an event object.  The  WorkingMemoryReteExpireAction tries to obtain the lock in NamedEntryPoint during call to retract().

Thread B (User's Thread):  attempts to execute a NamedEntryPoint insert() action simultaneously with the above.  The thread obtains the NamedEntryPoint lock and blocks waiting for the lock on actionQueue.

Deadlock:
Thread A is blocked waiting for NamedEntryPoint lock, owned by Thread B.
Thread B is blocked waiting for lock on actionQueue, owned by Thread A.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:10:57 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 22 Jun 2009 11:10:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2308) More Selenium
	Test
In-Reply-To: <27448854.1234455644582.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14284308.1245683457056.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473275#action_12473275 ] 

Viliam Rockai commented on JBPORTAL-2308:
-----------------------------------------

i've added a test for input validation for nearly all inputs in portal.

i didn't add tests for:
search inputs
samples

> More Selenium Test
> ------------------
>
>                 Key: JBPORTAL-2308
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2308
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>
> This is a wrapper task.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 09:37:07 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 22 Jun 2009 09:37:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1505) Optimise
 multiple message selectors on a queue
In-Reply-To: <5128840.1234454804372.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30493492.1245677827589.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1505:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Optimise multiple message selectors on a queue
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1505
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1505
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> In the case where there are multiple message selectors on a queue, the entire queue needs to be scanned for each delivery.
> We can optimise this by adding indexes on the queue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 10:34:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 22 Jun 2009 10:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBMESSAGING-1663) Release JBoss
 Messaging 2.0.0.Beta3
Message-ID: <31574340.1245681297366.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic deleted JBMESSAGING-1663:
-----------------------------------------


> Release JBoss Messaging 2.0.0.Beta3
> -----------------------------------
>
>                 Key: JBMESSAGING-1663
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1663
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 10:54:59 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 22 Jun 2009 10:54:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7659546.1245682499494.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1852:
-----------------------------------

    Assignee:     (was: jaikiran pai)


> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:45:56 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 22 Jun 2009 11:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBLOGGING-18) Creating a logger
 is privileged, but no doPrivilieged exists
In-Reply-To: <28909706.1245685436790.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28904142.1245685556695.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBLOGGING-18.
--------------------------------

    Resolution: Done


> Creating a logger is privileged, but no doPrivilieged exists
> ------------------------------------------------------------
>
>                 Key: JBLOGGING-18
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-18
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logmanager
>    Affects Versions: 1.0.0.GA-jboss-logmanager
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.1.0.CR3-jboss-logmanager
>
>
> Failures seen when security manager is enabled during test suite.  Logger construction calls setLevel() which is privileged, so logger creation must be privileged.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 10:52:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 22 Jun 2009 10:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7044)
 "java.io.NotSerializableException: java.util.HashMap$KeySet" error when
 ManagementView.getComponentTypes() is called over a remote connection
Message-ID: <23794448.1245682376767.JavaMail.jira@cloud.prod.atl2.jboss.com>

"java.io.NotSerializableException: java.util.HashMap$KeySet" error when ManagementView.getComponentTypes() is called over a remote connection
---------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7044
                 URL: https://jira.jboss.org/jira/browse/JBAS-7044
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Scott M Stark
             Fix For: JBossAS-5.2.0.Beta1


Exception in thread "main" org.jboss.remoting.InvocationFailureException: Unable to perform invocation; nested exception is:
        java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: java.util.HashMap$KeySet
        at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:142)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:891)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentTypes(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:165)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:118)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:112)
Caused by: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: java.util.HashMap$KeySet
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
        at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
        at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
        at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentTypes(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:165)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:118)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:112)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 9 more
Caused by: java.io.NotSerializableException: java.util.HashMap$KeySet
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
        at org.jboss.aop.joinpoint.InvocationResponse.writeExternal(InvocationResponse.java:100)
        at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1421)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1390)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:120)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:95)
        at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120)
        at org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:75)
        at org.jboss.remoting.transport.socket.ServerThread.versionedWrite(ServerThread.java:1006)
        at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:783)
        at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
        at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:524)
        at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:02:57 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 22 Jun 2009 11:02:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2223) create a
 hudson build for windows/IE testing
In-Reply-To: <4748061.1225462581379.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25380949.1245682977236.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473272#action_12473272 ] 

Viliam Rockai commented on JBPORTAL-2223:
-----------------------------------------

i've renamed the job to http://hudson.qa.jboss.com/hudson/view/JBoss Portal/job/jboss-portal-2.7-selenium-winIE7-
i wasn't able to find why i can't delete the workspace, this was the easiest way.

unfortunatelly, lots of work must be done until i make the suite stable.

anyway, we're not building portal on IE machine. i do the build in this job:
http://hudson.qa.jboss.com/hudson/view/JBoss%20Portal/job/jboss-portal-2.7-selenium-tests/
save the bundle on qa machine, and IE7 job just make use of this bundle.

is it enough or should i spend time on building of portal under windows?

> create a hudson build for windows/IE testing
> --------------------------------------------
>
>                 Key: JBPORTAL-2223
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2223
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:16:57 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 22 Jun 2009 11:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4493575.1245683817230.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf reassigned EJBTHREE-1852:
---------------------------------------

    Assignee: Carlo de Wolf


> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: Carlo de Wolf
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:08:57 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 22 Jun 2009 11:08:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2301) add perf test
	in selenium
In-Reply-To: <29209307.1233763904828.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26443515.1245683337097.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473274#action_12473274 ] 

Viliam Rockai commented on JBPORTAL-2301:
-----------------------------------------

i have difficulties with creating the dashboard with the portlet which was working for chris
https://jira.jboss.org/jira/browse/JBPORTAL-2040 

it make use of a class which seems to be missing in current portal 
http://docs.jboss.org/jbportal/v2.7.0.CR1/javadoc-bundle/cms/org/jboss/portal/cms/hibernate/state/Tools.html

anyway, i've written an e-mail to chris, hope we'll be able to solve it soon.

> add perf test in selenium
> -------------------------
>
>                 Key: JBPORTAL-2301
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2301
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core, Portal QA
>    Affects Versions: 2.7.1 Final
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>             Fix For: 2.8 Final
>
>
> Here what I think you need to do for simple perf testsuite. Let's create one for dashboard:
> 1. Add a mechanism to add 10K users with "user" role in database. user1, user2....user9999. It might be easier to write a sql script. See which one you can crunch easily.
> 2. Create a new dashboard test case, which logs in as each user that you created and add couple of more portlets in user's dashboard. Again sql script might be easier if there are not too many constraints to satisfy.
> 3. Add a new testcase which logs in as one of the user, goes to dashboard. Record the time taken as user goes through it.
> If I needed, I will write a smartfrog component which simulates about 1K users hitting portal and each user going through her dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:43:56 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 22 Jun 2009 11:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-18) Creating a logger
 is privileged, but no doPrivilieged exists
Message-ID: <28909706.1245685436790.JavaMail.jira@cloud.prod.atl2.jboss.com>

Creating a logger is privileged, but no doPrivilieged exists
------------------------------------------------------------

                 Key: JBLOGGING-18
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-18
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-logmanager
    Affects Versions: 1.0.0.GA-jboss-logmanager
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 1.1.0.CR3-jboss-logmanager


Failures seen when security manager is enabled during test suite.  Logger construction calls setLevel() which is privileged, so logger creation must be privileged.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:16:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 22 Jun 2009 11:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-2380) add dnd test to
 Dashboard test case
In-Reply-To: <2223063.1240588306874.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15349460.1245683816896.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Viliam Rockai resolved JBPORTAL-2380.
-------------------------------------

    Resolution: Done


> add dnd test to Dashboard test case
> -----------------------------------
>
>                 Key: JBPORTAL-2380
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2380
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:18:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 22 Jun 2009 11:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2392) Selenium tests
	for XSS
In-Reply-To: <23069268.1242226847011.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31110396.1245683936662.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473278#action_12473278 ] 

Viliam Rockai commented on JBPORTAL-2392:
-----------------------------------------

i've added input validation tests for nearly all inputs in portal, checking for validation error message to be present on the screen after pressing relevant submit button.

i didn't add input validation for samples page and search inputs.

still waiting for last fixes from chris, probably some assert messages (in assert.properties) would have to be tweaked

> Selenium tests for XSS
> ----------------------
>
>                 Key: JBPORTAL-2392
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2392
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal QA
>            Reporter: Viliam Rockai
>            Assignee: Viliam Rockai
>
> Testing XSS on inputs in portal GUI had to be implemented.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:49:56 2009
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Mon, 22 Jun 2009 11:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2223) create a
 hudson build for windows/IE testing
In-Reply-To: <4748061.1225462581379.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2681711.1245685796577.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473286#action_12473286 ] 

Prabhat Jha commented on JBPORTAL-2223:
---------------------------------------

No need to spend time on building it on windows.

> create a hudson build for windows/IE testing
> --------------------------------------------
>
>                 Key: JBPORTAL-2223
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2223
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 12:26:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 22 Jun 2009 12:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2308) More Selenium
	Test
In-Reply-To: <27448854.1234455644582.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10901210.1245688016636.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473297#action_12473297 ] 

Viliam Rockai commented on JBPORTAL-2308:
-----------------------------------------

search users in admin interface
search users in role members in admin interface
search in cms

> More Selenium Test
> ------------------
>
>                 Key: JBPORTAL-2308
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2308
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>
> This is a wrapper task.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 12:24:56 2009
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Mon, 22 Jun 2009 12:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2308) More Selenium
	Test
In-Reply-To: <27448854.1234455644582.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28519891.1245687896536.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473296#action_12473296 ] 

Prabhat Jha commented on JBPORTAL-2308:
---------------------------------------

anything in samples doesn't need to be XSS validated.

Where is "search inputs"?



> More Selenium Test
> ------------------
>
>                 Key: JBPORTAL-2308
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2308
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>
> This is a wrapper task.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 16:04:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 22 Jun 2009 16:04:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1728584.1245701097019.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6888:
---------------------------------


I've upgraded my local workspace to  use AOP 2.1.2.GA and still issues with aoptest.sar.  Specifically,
2009-06-22 14:26:49,566 INFO  [org.jboss.test.aop.bean.AOPTester] (HDScanner) RUNNING TEST BASIC
2009-06-22 14:26:49,567 ERROR [org.jboss.test.aop.bean.AOPTester] (HDScanner) failed
java.lang.RuntimeException: POJO is not instanceof Advised
        at org.jboss.test.aop.bean.AOPTester.testBasic(AOPTester.java:110)
        at org.jboss.test.aop.bean.AOPTester.startService(AOPTester.java:83)

I'll look at all the tests in the description of this JIRA to see what errors are now being encountered.

> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Flavia Rainone
>         Attachments: server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 16:08:56 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 22 Jun 2009 16:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBLOGGING-19) New formatters
 don't print stack traces
In-Reply-To: <5800232.1245701336575.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9083916.1245701336759.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBLOGGING-19.
--------------------------------

    Resolution: Done


> New formatters don't print stack traces
> ---------------------------------------
>
>                 Key: JBLOGGING-19
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-19
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logmanager
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.1.0.CR3-jboss-logmanager
>
>
> The new logmanager formatter for the message string does not output stack traces, making debugging rather interesting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 10:48:57 2009
From: jira-events at lists.jboss.org (Steve Ebersole (JIRA))
Date: Mon, 22 Jun 2009 10:48:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (HIBERNATE-115) Bug in
 AbstractEntityPersister for generated version properties
In-Reply-To: <24166695.1245677170570.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12347916.1245682137843.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/HIBERNATE-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Ebersole closed HIBERNATE-115.
------------------------------------

    Resolution: Rejected


This is not true.  The version field should be updated on any state change.

> Bug in AbstractEntityPersister for generated version properties
> ---------------------------------------------------------------
>
>                 Key: HIBERNATE-115
>                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-115
>             Project: Hibernate
>          Issue Type: Bug
>         Environment: Jboss 4.2.3 GA, Hibernate 3.3.1, MSSQL Server 2005, actual Merlia DB Driver 7.0.5
>            Reporter: Juergen W
>            Assignee: Steve Ebersole
>
> Following problem:
> we're using following configuration for our entities (dynamic-update="true" , dynamic-insert="true" , select-before-update="true", the version property is generated by the database and is read-only )
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
> "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
> <hibernate-mapping>
> <class name="de.xxx.xxx.Angebot"  
>    table="ANGeBot" 
>    dynamic-update="true"  
>    dynamic-insert="true" 
>    select-before-update="true">
>  
> <id name="angbId" type="java.lang.Integer" column="ANGB_ID" unsaved-value="0">
> 	<generator class="identity"/>
> </id>
>      <version name="Timestamp" type="binary" column="ANGB_Timestamp" generated="always" insert="false" unsaved-value="undefined"/>  
> 	<property name="Aenderungsdatum" column="ANGB_Aenderungsdatum" type="java.util.Date" length="23"/>
> 	<property name="Aenderungsperson" column="ANGB_Aenderungsperson" type="java.lang.String" length="30"/>
> 	<property name="AnbieterAnsprechpartner" column="ANGB_Anbieter_Ansprechpartner" type="java.lang.String" length="100"/>
>        ... additional props...
> </class>
> </hibernate-mapping>
> If we made some changes to a row, hibernate should update only the "dirty fields" and NOT the version field. But hibernate tries to update the version property too, and thus we got the  db exception, the version column is not updateable.
> Hibernate generates following updatestatement, if we change the field ANGB_ANBIETER_ANSPRECHPARTNER
>  UPDATE
>             V_AMVW_ANGEBOT
>         SET
>             ANGB_TIMESTAMP=?,    <----  THATs WRONG
>             ANGB_ANBIETER_ANSPRECHPARTNER=?
>         WHERE
>             ANGB_ID=?
>             AND ANGB_TIMESTAMP=?
> I think, in the org.hibernate.persister.entity.AbstractEntityPersister in the method getPropertiesToUpdate() following "if statement" is missing if the version property is generated:
> 		if ( isVersioned()) {
> 			propsToUpdate[ getVersionProperty() ] =
> 				Versioning.isVersionIncrementRequired( dirtyProperties, hasDirtyCollection, getPropertyVersionability() );
> 		}
> If I change the "if" statement to following:
> 		if ( isVersioned() && !isVersionPropertyGenerated()) {
> 			propsToUpdate[ getVersionProperty() ] =
> 				Versioning.isVersionIncrementRequired( dirtyProperties, hasDirtyCollection, getPropertyVersionability() );
> 		}
> than it is working

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 10:46:59 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 22 Jun 2009 10:46:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31563199.1245682019160.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473264#action_12473264 ] 

jaikiran pai commented on EJBTHREE-1852:
----------------------------------------

I'll try to reproduce this with the default interceptors. Thanks for letting us know.


> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 11:14:56 2009
From: jira-events at lists.jboss.org (Viliam Rockai (JIRA))
Date: Mon, 22 Jun 2009 11:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2311) CMS tests with
	workflow on
In-Reply-To: <775677.1234458884428.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3552008.1245683696934.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473276#action_12473276 ] 

Viliam Rockai commented on JBPORTAL-2311:
-----------------------------------------

i wanted to resolve this issue, but i have found that the job has some problems lately:
http://hudson.qa.jboss.com/hudson/view/JBoss%20Portal/job/jboss-portal-2.7-workflow-selenium-tests/

i will look at that

> CMS tests with workflow on
> --------------------------
>
>                 Key: JBPORTAL-2311
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2311
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Prabhat Jha
>            Assignee: Viliam Rockai
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 16:17:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 22 Jun 2009 16:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6889) tests in
 tests-aop-scoped failing with IBM JDK
In-Reply-To: <7099808.1242045886541.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16115752.1245701876966.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6889:
---------------------------------


Upgrading my local workspace with 2.1.0.GA, still see errors in these tests:
Caused by: java.lang.ExceptionInInitializerError
        at java.lang.J9VMInternals.initialize(J9VMInternals.java:218)
        at org.jboss.test.aop.jdk15annotated.ScopedAnnotatedTester.testCompostition(ScopedAnnotatedTester.java:144)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
Caused by: java.lang.NullPointerException
        at org.jboss.aop.instrument.JoinPointGenerator.findAdvisedField(JoinPointGenerator.java:499)
        at org.jboss.aop.instrument.JoinPointGenerator.&lt;init&gt;(JoinPointGenerator.java:187)
        at org.jboss.aop.instrument.MethodJoinPointGenerator.&lt;init&gt;(MethodJoinPointGenerator.java:74)
        at org.jboss.aop.GeneratedClassAdvisor$ClassAdvisorStrategy.getJoinPointGenerator(GeneratedClassAdvisor.java:1311)
        at org.jboss.aop.GeneratedClassAdvisor.getJoinPointGenerator(GeneratedClassAdvisor.java:778)
        at org.jboss.aop.GeneratedClassAdvisor.fullWorkFinalizeMethodChain(GeneratedClassAdvisor.java:632)
        at org.jboss.aop.GeneratedClassAdvisor.finalizeMethodChain(GeneratedClassAdvisor.java:596)
        at org.jboss.aop.GeneratedClassAdvisor.finalizeChains(GeneratedClassAdvisor.java:577)
        at org.jboss.aop.ClassAdvisor.createInterceptorChains(ClassAdvisor.java:609)
        at org.jboss.aop.GeneratedClassAdvisor.access$201(GeneratedClassAdvisor.java:65)
        at org.jboss.aop.GeneratedClassAdvisor$ClassAdvisorStrategy.createInterceptorChains(GeneratedClassAdvisor.java:1303)
        at org.jboss.aop.GeneratedClassAdvisor.createInterceptorChains(GeneratedClassAdvisor.java:407)


> tests in tests-aop-scoped failing with IBM JDK
> ----------------------------------------------
>
>                 Key: JBAS-6889
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6889
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: TEST-org.jboss.test.aop.test.ScopedAnnotatedTestCase-aop-scoped.xml
>
>
> Tests in the tests-aop-scoped target of JBoss AS testsuite are failing.
> The tests are:
> org.jboss.test.aop.test.ScopedAnnotatedTestCase
> org.jboss.test.aop.test.ScopedAttachUnitTestCase
> org.jboss.test.aop.test.ScopedEarWithClassesInWebInfTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseLoadedScopedNoParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseLoadedScopedParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseNotLoadedScopedNoParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseNotLoadedScopedParentDelegationTestCase
> org.jboss.test.aop.test.ScopedUnitTestCase
> org.jboss.test.aop.test.ScopedWovenDependencyTestCase
> The error message is:
> javax.management.RuntimeErrorException
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:182)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: java.lang.ExceptionInInitializerError
> 	at java.lang.J9VMInternals.initialize(J9VMInternals.java:216)
> 	at org.jboss.test.aop.jdk15annotated.ScopedAnnotatedTester.testBinding(ScopedAnnotatedTester.java:50)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.aop.Domain$1.run(Domain.java:124)
> 	at org.jboss.aop.Domain$1.run(Domain.java:121)
> 	at java.security.AccessController.doPrivileged(AccessController.java:197)
> 	at org.jboss.aop.Domain.getDomainName(Domain.java:119)
> 	at org.jboss.test.aop.jdk15annotated.POJO$POJOAdvisor.initialise(POJO$POJOAdvisor.java)
> 	at org.jboss.test.aop.jdk15annotated.POJO$POJOAdvisor.<init>(POJO$POJOAdvisor.java)
> 	at org.jboss.test.aop.jdk15annotated.POJO.<clinit>(POJO.java)
> 	at java.lang.J9VMInternals.initializeImpl(Native Method)
> 	at java.lang.J9VMInternals.initialize(J9VMInternals.java:194)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 16:44:56 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Mon, 22 Jun 2009 16:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1853) NPE upon
 lookup of errorneous EJB
In-Reply-To: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16458639.1245703496485.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473325#action_12473325 ] 

Ondrej ?i?ka commented on EJBTHREE-1853:
----------------------------------------

(20:48:52) ALR: ozizka: Please file a JIRA for *ANY* NPEs encountered
(20:49:02) ALR: As they should instead be a descriptive failure
(20:49:21) ALR: Even though yours is wrapped w/ some description, it doesn't say why.

> NPE upon lookup of errorneous EJB
> ---------------------------------
>
>                 Key: EJBTHREE-1853
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Ondrej ?i?ka
>         Attachments: EJBlookup-NPE.zip, log.txt
>
>
> When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.
> Steps to reproduce:
> 1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
> 2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
>     This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.
> Upon ctx.lookup(), the NPE occurs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 18:49:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 22 Jun 2009 18:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1853) NPE upon lookup
 of errorneous EJB
In-Reply-To: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15424238.1245710997011.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated EJBTHREE-1853:
------------------------------------------

    Environment: 
JBAS:  AS 5.1.0  (from the JBPAPP branch)
Sun JDK jdk1.5.0_17

  was:
JBAS:  jboss-5.0.0.Beta  (from the JBPAPP branch)
Sun JDK jdk1.5.0_17



Probably some sort of assertion in the proxy code, instead of NPE, as well as a jboss-metadata validation check (in the post-processing chain) that @Remote/@Local contains an interface would be appropriate.

> NPE upon lookup of errorneous EJB
> ---------------------------------
>
>                 Key: EJBTHREE-1853
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBAS:  AS 5.1.0  (from the JBPAPP branch)
> Sun JDK jdk1.5.0_17
>            Reporter: Ondrej ?i?ka
>            Assignee: Andrew Lee Rubinger
>         Attachments: EJBlookup-NPE.zip, log.txt
>
>
> When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.
> Steps to reproduce:
> 1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
> 2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
>     This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.
> Upon ctx.lookup(), the NPE occurs.
> ----------------
> The EJB has:
> public interface Counter { }
> @Remote
> public interface CounterRemote extends Counter { }
> @Stateful
> @Remote(CounterBean.class)
> public class CounterBean implements Counter { }
> -------
> The client jar contains (incomplete list):
> public interface Counter { }
> @Stateful
> public class CounterBean implements Counter { }
> (this wild combination arose when testing :)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 17:26:56 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Mon, 22 Jun 2009 17:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1853) NPE upon lookup
 of errorneous EJB
In-Reply-To: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23623875.1245706016787.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka reassigned EJBTHREE-1853:
--------------------------------------

    Assignee: Andrew Lee Rubinger


> NPE upon lookup of errorneous EJB
> ---------------------------------
>
>                 Key: EJBTHREE-1853
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBAS:  jboss-5.0.0.Beta  (from the JBPAPP branch)
> Sun JDK jdk1.5.0_17
>            Reporter: Ondrej ?i?ka
>            Assignee: Andrew Lee Rubinger
>         Attachments: EJBlookup-NPE.zip, log.txt
>
>
> When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.
> Steps to reproduce:
> 1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
> 2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
>     This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.
> Upon ctx.lookup(), the NPE occurs.
> ----------------
> The EJB has:
> public interface Counter { }
> @Remote
> public interface CounterRemote extends Counter { }
> @Stateful
> @Remote(CounterBean.class)
> public class CounterBean implements Counter { }
> -------
> The client jar contains (incomplete list):
> public interface Counter { }
> @Stateful
> public class CounterBean implements Counter { }
> (this wild combination arose when testing :)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 16:08:56 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 22 Jun 2009 16:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-19) New formatters
 don't print stack traces
Message-ID: <5800232.1245701336575.JavaMail.jira@cloud.prod.atl2.jboss.com>

New formatters don't print stack traces
---------------------------------------

                 Key: JBLOGGING-19
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-19
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-logmanager
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 1.1.0.CR3-jboss-logmanager


The new logmanager formatter for the message string does not output stack traces, making debugging rather interesting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 16:32:56 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Mon, 22 Jun 2009 16:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1853) NPE upon lookup
 of errorneous EJB
Message-ID: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE upon lookup of errorneous EJB
---------------------------------

                 Key: EJBTHREE-1853
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Ondrej ?i?ka


When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.

Steps to reproduce:
1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
    This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.

Upon ctx.lookup(), the NPE occurs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 16:58:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 22 Jun 2009 16:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <31498429.1245704336539.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7032:
---------------------------------


John, not sure if you saw my comment in the referenced forum post but I cannot reproduce this error when deploying via the console.  Is there more information about your environment you can provide as I'm interested to know how you got into this state

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 22 16:42:56 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Mon, 22 Jun 2009 16:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1853) NPE upon lookup
 of errorneous EJB
In-Reply-To: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16511485.1245703376991.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka updated EJBTHREE-1853:
-----------------------------------

    Attachment: log.txt


Stack trace. Also contains mvn exec command skeleton.

> NPE upon lookup of errorneous EJB
> ---------------------------------
>
>                 Key: EJBTHREE-1853
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Ondrej ?i?ka
>         Attachments: EJBlookup-NPE.zip, log.txt
>
>
> When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.
> Steps to reproduce:
> 1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
> 2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
>     This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.
> Upon ctx.lookup(), the NPE occurs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 16:56:56 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Mon, 22 Jun 2009 16:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1853) NPE upon lookup
 of errorneous EJB
In-Reply-To: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9243431.1245704216877.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka updated EJBTHREE-1853:
-----------------------------------

    Environment: 
JBAS:  jboss-5.0.0.Beta  (from the JBPAPP branch)
Sun JDK jdk1.5.0_17
    Description: 
When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.

Steps to reproduce:
1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
    This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.

Upon ctx.lookup(), the NPE occurs.

----------------

The EJB has:

public interface Counter { }

@Remote
public interface CounterRemote extends Counter { }

@Stateful
@Remote(CounterBean.class)
public class CounterBean implements Counter { }

-------

The client jar contains (incomplete list):

public interface Counter { }

@Stateful
public class CounterBean implements Counter { }

(this wild combination arose when testing :)

  was:
When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.

Steps to reproduce:
1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
    This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.

Upon ctx.lookup(), the NPE occurs.



> NPE upon lookup of errorneous EJB
> ---------------------------------
>
>                 Key: EJBTHREE-1853
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBAS:  jboss-5.0.0.Beta  (from the JBPAPP branch)
> Sun JDK jdk1.5.0_17
>            Reporter: Ondrej ?i?ka
>         Attachments: EJBlookup-NPE.zip, log.txt
>
>
> When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.
> Steps to reproduce:
> 1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
> 2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
>     This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.
> Upon ctx.lookup(), the NPE occurs.
> ----------------
> The EJB has:
> public interface Counter { }
> @Remote
> public interface CounterRemote extends Counter { }
> @Stateful
> @Remote(CounterBean.class)
> public class CounterBean implements Counter { }
> -------
> The client jar contains (incomplete list):
> public interface Counter { }
> @Stateful
> public class CounterBean implements Counter { }
> (this wild combination arose when testing :)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 17:26:56 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Mon, 22 Jun 2009 17:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1853) NPE upon
 lookup of errorneous EJB
In-Reply-To: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <330704.1245706016640.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473332#action_12473332 ] 

Ondrej ?i?ka commented on EJBTHREE-1853:
----------------------------------------

By the way, after undeployment of the EJB (probably successful - not listed in JMX console), still there are traces of it in the JNDI namespace:

Global JNDI Namespace
...
  +- CounterBean (class: org.jnp.interfaces.NamingContext)
  |   +- remote-ejbtest.stateful.bean.CounterBean (class: Proxy for: ejbtest.stateful.bean.CounterBean)
  |   +- remote (class: Proxy for: ejbtest.stateful.bean.CounterBean)

This shouldn't happen either, should it?

> NPE upon lookup of errorneous EJB
> ---------------------------------
>
>                 Key: EJBTHREE-1853
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBAS:  jboss-5.0.0.Beta  (from the JBPAPP branch)
> Sun JDK jdk1.5.0_17
>            Reporter: Ondrej ?i?ka
>         Attachments: EJBlookup-NPE.zip, log.txt
>
>
> When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.
> Steps to reproduce:
> 1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
> 2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
>     This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.
> Upon ctx.lookup(), the NPE occurs.
> ----------------
> The EJB has:
> public interface Counter { }
> @Remote
> public interface CounterRemote extends Counter { }
> @Stateful
> @Remote(CounterBean.class)
> public class CounterBean implements Counter { }
> -------
> The client jar contains (incomplete list):
> public interface Counter { }
> @Stateful
> public class CounterBean implements Counter { }
> (this wild combination arose when testing :)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 16:34:56 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Mon, 22 Jun 2009 16:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1853) NPE upon lookup
 of errorneous EJB
In-Reply-To: <23591450.1245702776564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16995551.1245702896491.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka updated EJBTHREE-1853:
-----------------------------------

    Attachment: EJBlookup-NPE.zip


EJB, client, and Maven projects for both.

> NPE upon lookup of errorneous EJB
> ---------------------------------
>
>                 Key: EJBTHREE-1853
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1853
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Ondrej ?i?ka
>         Attachments: EJBlookup-NPE.zip
>
>
> When a bad EJB is deployed and then looked up remotely, a NPE is thrown - see attached stack trace.
> Steps to reproduce:
> 1) Start AS 5 and deploy the attached EJB - ejb-stateful-1.0-SNAPSHOT.jar .
> 2) Run the client - EjbClient-1.0-SNAPSHOT.jar , class ejbtest.EjbClient.StatefulClient
>     This has quite many dependencies, so it's good idea to open the mvn project (in the attached zip) and use some IDE's "Run file" function.
> Upon ctx.lookup(), the NPE occurs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 22 22:23:56 2009
From: jira-events at lists.jboss.org (Dickson Lui (JIRA))
Date: Mon, 22 Jun 2009 22:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7045) Request to have
 examples / steps to setup simple clustering
Message-ID: <1655375.1245723836613.JavaMail.jira@cloud.prod.atl2.jboss.com>

Request to have examples / steps to setup simple clustering
-----------------------------------------------------------

                 Key: JBAS-7045
                 URL: https://jira.jboss.org/jira/browse/JBAS-7045
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Docs/Clustering Guide
         Environment: Documentation
            Reporter: Dickson Lui
            Priority: Optional


Suggestion for Docs/Clustering Guide

at least one full steps example for a simple clustering setup; steps by steps to setup the simple one that help the new user a lot. 

1. first step to do (  2 JBoss running in 2 machines; assume normal installation except for clustering?)

2. after it works fine individually, next step to do ( what???? )

3. next step, ....

4. Finally, how to test the clustering.


I think the original document is a kind of definition. I think the end user mostly want to know how to set and then deeply understand the details if they need.

I hope that all documentation could have more examples / steps to show the end user to implement the specific configuration. Thanks in advance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 00:59:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 23 Jun 2009 00:59:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6777) 'interleaving' prop
 on
 connection factories and datasources is always null, even when underlying
 ds.xml file contains the interleaving element
In-Reply-To: <595967.1239722543600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15996071.1245733197932.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-6777.
---------------------------------

    Resolution: Partially Completed


To be able to update the interleaving value requires a deployment restart. I have updated the activationPolicy to be DEPLOYMENT_RESTART.

> 'interleaving' prop on connection factories and datasources is always null, even when underlying ds.xml file contains the interleaving element
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6777
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6777
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> My ds.xml file:
> <connection-factories>
>     <tx-connection-factory>
>         <jndi-name>MyXATxCF</jndi-name>
>         <rar-name>jms-ra.rar</rar-name>
>         <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
>         ...
>         <interleaving/>
>     </tx-connection-factory>
> </connection-factories>
> But the interleaving ManagedProperty on this CF is still null, rather than true:
>   name=interleaving, viewUse=NONE, readOnly=false, mandatory=false, removed=false, type=SimpleMetaType:java.lang.Boolean, value=  <<<null>>>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 01:05:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 23 Jun 2009 01:05:56 -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: <20182267.1245733556754.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1661:
------------------------------------

    Fix Version/s: 1.4.5.GA
                       (was: 1.4.4.GA)


> 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://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.5.GA
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 02:33:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 23 Jun 2009 02:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-213) add JCA DTD files
Message-ID: <2485970.1245738836463.JavaMail.jira@cloud.prod.atl2.jboss.com>

add JCA DTD files
-----------------

                 Key: JBMETA-213
                 URL: https://jira.jboss.org/jira/browse/JBMETA-213
             Project: JBoss Metadata
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.2.Beta2


add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/comon

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 02:44:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 23 Jun 2009 02:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-213) add JCA DTD files
In-Reply-To: <2485970.1245738836463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6765797.1245739496611.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBMETA-213.
-------------------------------

    Resolution: Done


> add JCA DTD files
> -----------------
>
>                 Key: JBMETA-213
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-213
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.2.Beta2
>
>
> add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/rar

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 02:44:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 23 Jun 2009 02:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-213) add JCA DTD files
In-Reply-To: <2485970.1245738836463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24013115.1245739496484.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBMETA-213:
------------------------------

    Description: add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/rar  (was: add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/comon)


> add JCA DTD files
> -----------------
>
>                 Key: JBMETA-213
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-213
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.2.Beta2
>
>
> add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/rar

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 04:13:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 23 Jun 2009 04:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16690090.1245744836925.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated EJBTHREE-1852:
------------------------------------

    Fix Version/s: 1.1.8


> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.8
>
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 04:20:34 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 23 Jun 2009 04:20:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20319660.1245745234257.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved EJBTHREE-1852.
-------------------------------------

    Resolution: Done


I've removed the obsolete code from InterceptorInfoRepository which also caused this error.

Note that instantiating an InterceptorInfoRepository will now produce a warning:
09:49:32,195 WARN  [InterceptorInfoRepository] EJBTHREE-1852: InterceptorInfoRepository is deprecated

These should be dealt with once the next release of EJB 3 is integrated. A bean developer can safely ignore the warnings.

> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.8
>
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 04:21:57 2009
From: jira-events at lists.jboss.org (Corneil du Plessis (JIRA))
Date: Tue, 23 Jun 2009 04:21:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2136) Simple match rule
 fails on 5.0.1 and works on 4.0.7
Message-ID: <17964558.1245745317053.JavaMail.jira@cloud.prod.atl2.jboss.com>

Simple match rule fails on 5.0.1 and works on 4.0.7
---------------------------------------------------

                 Key: JBRULES-2136
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2136
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Corneil du Plessis
            Assignee: Mark Proctor


A simple rule that worked in 4.0.7 fails in 5.0.1
An Eclipse project to illustrate the problem will be attached to this issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 04:25:58 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Tue, 23 Jun 2009 04:25:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-421) Configuring
 security with "-jboss-beans.xml" should trim module options
Message-ID: <21788667.1245745558863.JavaMail.jira@cloud.prod.atl2.jboss.com>

Configuring security with "-jboss-beans.xml" should trim module options
-----------------------------------------------------------------------

                 Key: SECURITY-421
                 URL: https://jira.jboss.org/jira/browse/SECURITY-421
             Project: JBoss Security and Identity Management
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Wolfgang Knauf
            Assignee: Anil Saldhana


See the linked forum post: if security is configured through a "...-jboss-beans.xml" file, then the module options are not trimmed. For a DatabaseServerLoginModule, this is fatal for the "dsJndiName" attribute, because even logging the security layer reports a "NameNotFoundException", but the JndiName in the error message seems valid.

E.g. Eclipse might add additional newlines when the xml file is autoformatted.

The old approach with "login-config.xml" seems to do this trimming, so it is even more confusing for users, especially if an old file is migrated (as I did). I would call this an regression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 04:42:08 2009
From: jira-events at lists.jboss.org (Corneil du Plessis (JIRA))
Date: Tue, 23 Jun 2009 04:42:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2136) Simple match rule
 fails on 5.0.1 and works on 4.0.7
In-Reply-To: <17964558.1245745317053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1399428.1245746528084.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Corneil du Plessis updated JBRULES-2136:
----------------------------------------

    Attachment: drools-test.zip


This is an Eclipse project file.
The relevant files required from Drools/lib is not included in this project file.

> Simple match rule fails on 5.0.1 and works on 4.0.7
> ---------------------------------------------------
>
>                 Key: JBRULES-2136
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2136
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Corneil du Plessis
>            Assignee: Mark Proctor
>         Attachments: drools-test.zip
>
>
> A simple rule that worked in 4.0.7 fails in 5.0.1
> An Eclipse project to illustrate the problem will be attached to this issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 05:39:56 2009
From: jira-events at lists.jboss.org (Osamu Yokomizo (JIRA))
Date: Tue, 23 Jun 2009 05:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8012311.1245749996807.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473389#action_12473389 ] 

Osamu Yokomizo commented on EJBTHREE-995:
-----------------------------------------

Hi , Andrew.

It was not generated in AS 5.1.0.
Are not you mended in 4.x ?

1: deploy sample-AS5x.jar
2: execute client SampleClient.
   SampleClient is in sample-AS5x.jar

server.log
====

17:31:44,187 INFO  [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 27s:859ms
17:32:13,796 WARN  [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used
 via the bean container
17:32:13,796 WARN  [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used
 via the bean container
17:32:13,812 INFO  [STDOUT] ut.begin():6
17:32:13,812 INFO  [STDOUT] afterBegin()
17:32:13,828 INFO  [STDOUT] beforeCompletion():
17:32:13,828 INFO  [STDOUT] afterCompletion():true


> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>         Attachments: sample.jar, src.zip
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 05:43:56 2009
From: jira-events at lists.jboss.org (Osamu Yokomizo (JIRA))
Date: Tue, 23 Jun 2009 05:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7102235.1245750236868.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Osamu Yokomizo updated EJBTHREE-995:
------------------------------------

    Attachment: src-AS5x.zip


This is source files for AS5x. 

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>         Attachments: sample-AS5x.jar, sample.jar, src-AS5x.zip, src.zip
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 05:43:57 2009
From: jira-events at lists.jboss.org (Osamu Yokomizo (JIRA))
Date: Tue, 23 Jun 2009 05:43:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-995) Multiple
 Synchronizations registered for a SFSB.
In-Reply-To: <7402020.1182908937592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3113342.1245750237112.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Osamu Yokomizo updated EJBTHREE-995:
------------------------------------

    Attachment: sample-AS5x.jar


This is jar(EJB and Client)  for AS5x

> Multiple Synchronizations registered for a SFSB.
> ------------------------------------------------
>
>                 Key: EJBTHREE-995
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-995
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Gavin King
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: 1.0.0-Beta9
>
>         Attachments: sample-AS5x.jar, sample.jar, src-AS5x.zip, src.zip
>
>
> It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 06:19:57 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Tue, 23 Jun 2009 06:19:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7023) Web Beans
 integration points container task
In-Reply-To: <1066442.1245083216361.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <615257.1245752397241.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pete Muir updated JBAS-7023:
----------------------------

    Priority: Critical  (was: Major)


> Web Beans integration points container task
> -------------------------------------------
>
>                 Key: JBAS-7023
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7023
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Beans
>            Reporter: Pete Muir
>            Assignee: Pete Muir
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Container task for Web Beans integration tasks to allow JBoss AS to fully pass TCK

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 06:23:56 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 23 Jun 2009 06:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMICROCONT-446) bean-deployer
 xsds don't contain web references
In-Reply-To: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25411578.1245752636535.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMICROCONT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned JBMICROCONT-446:
--------------------------------------

    Assignee: Kabir Khan


> bean-deployer xsds don't contain web references
> -----------------------------------------------
>
>                 Key: JBMICROCONT-446
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Wolfgang Knauf
>            Assignee: Kabir Khan
>
> bean-deployer_2_0.xsd:
>    <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
> =>should point. 
>    <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">
> The comment for a sample instance should also contain a schema location attribute:
>          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xmlns="urn:jboss:bean-deployer:2.0"
>             xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">
> ==================
> bean-deployer_1_0.xsd:
> The comment for a sample instance should point to the web schema location:
>          <deployment
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
>             xmlns="urn:jboss:bean-deployer">
> =================
> policy_1_0.xsd:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
> should be:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>
> =================
> bean-deployer_2_0.xsd raises validation errors in Eclipse:
> -rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
> -src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
> According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 06:27:56 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Tue, 23 Jun 2009 06:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7046) Support CDI
 injection into managed Servlet objects
Message-ID: <24256304.1245752876415.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support CDI injection into managed Servlet objects
--------------------------------------------------

                 Key: JBAS-7046
                 URL: https://jira.jboss.org/jira/browse/JBAS-7046
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Pete Muir
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 07:17:56 2009
From: jira-events at lists.jboss.org (Tobias Meyer (JIRA))
Date: Tue, 23 Jun 2009 07:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-85) IllegalAccessError
 when trying to call clone() on a class generated by ProxyFactory
Message-ID: <15165406.1245755876804.JavaMail.jira@cloud.prod.atl2.jboss.com>

IllegalAccessError when trying to call clone() on a class generated by ProxyFactory
-----------------------------------------------------------------------------------

                 Key: JASSIST-85
                 URL: https://jira.jboss.org/jira/browse/JASSIST-85
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.10.0.GA
            Reporter: Tobias Meyer
            Assignee: Shigeru Chiba


Hibernate 3.3 uses javassist (by default) to generate LazyInitializer Objects.
If a lazily loaded object implements the clone() method, and makes it public, there will be a runtime IllegalAccessError because the javassist proxy object exports the protected definition of Object.clone() instead of the definition in the MethodHandler's Interface.

The supplied patch makes the ProxyFactory to never reduce the visibility of a public method, even if implemented in a higher interface or the superclass.
Normally the java compiler would catch such an error, so this is assumed to be save.

Side effect is of course that a superclass method given to ProxyFactory might not be called as before because a public definition of the MethodHandler (Interface) overloads it.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 08:05:56 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 23 Jun 2009 08:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-740) More workarounds for
 bug in IBM's Class.getDeclaringClass() implementation
Message-ID: <10151921.1245758756509.JavaMail.jira@cloud.prod.atl2.jboss.com>

More workarounds for bug in IBM's Class.getDeclaringClass() implementation
--------------------------------------------------------------------------

                 Key: JBAOP-740
                 URL: https://jira.jboss.org/jira/browse/JBAOP-740
             Project: JBoss AOP
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.2.GA
            Reporter: Kabir Khan
             Fix For: 2.1.3.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 08:05:56 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 23 Jun 2009 08:05:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-740) More workarounds
 for bug in IBM's Class.getDeclaringClass() implementation
In-Reply-To: <10151921.1245758756509.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1669481.1245758756678.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAOP-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473414#action_12473414 ] 

Kabir Khan commented on JBAOP-740:
----------------------------------

See linked issues for a more detailed description

> More workarounds for bug in IBM's Class.getDeclaringClass() implementation
> --------------------------------------------------------------------------
>
>                 Key: JBAOP-740
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-740
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.2.GA
>            Reporter: Kabir Khan
>             Fix For: 2.1.3.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 07:52:57 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 23 Jun 2009 07:52:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5239199.1245757977288.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated JBAS-6888:
-----------------------------

    Attachment: RunIt.java


Having run the standalone AOP tests on the IBM JDK, it seems to be more problems with Class.getDeclaringClass(). I wrote a simple test in RunIt.java, which works as expected both for Class.getDeclaringClass() and Class.getEnclosingClass() on both Sun and IBM JVMs

>From what I can see though, the places where we actually make these calls is on generated classes (i.e. the Advisors), and these methods are native, so maybe it is getting confused somehow because the classes did not exist when the classloader was initialised. I will see if I can fix it.

Does anybody know of a reliable way to determine from java if running in IBMs JDK?

> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Flavia Rainone
>         Attachments: RunIt.java, server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 09:30:57 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 23 Jun 2009 09:30:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7044)
 "java.io.NotSerializableException: java.util.HashMap$KeySet" error when
 ManagementView.getComponentTypes() is called over a remote connection
In-Reply-To: <23794448.1245682376767.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20891070.1245763857428.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-7044.
---------------------------------

    Resolution: Done


Fixed by ensuring the set returned was serializable

> "java.io.NotSerializableException: java.util.HashMap$KeySet" error when ManagementView.getComponentTypes() is called over a remote connection
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7044
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7044
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Exception in thread "main" org.jboss.remoting.InvocationFailureException: Unable to perform invocation; nested exception is:
>         java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: java.util.HashMap$KeySet
>         at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:142)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:891)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentTypes(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:165)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:118)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:112)
> Caused by: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: java.util.HashMap$KeySet
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1333)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentTypes(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:165)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:118)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:112)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         ... 9 more
> Caused by: java.io.NotSerializableException: java.util.HashMap$KeySet
>         at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
>         at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
>         at org.jboss.aop.joinpoint.InvocationResponse.writeExternal(InvocationResponse.java:100)
>         at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1421)
>         at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1390)
>         at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
>         at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
>         at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
>         at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
>         at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
>         at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:120)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:95)
>         at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120)
>         at org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:75)
>         at org.jboss.remoting.transport.socket.ServerThread.versionedWrite(ServerThread.java:1006)
>         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:783)
>         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
>         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:524)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:01:57 2009
From: jira-events at lists.jboss.org (Corneil du Plessis (JIRA))
Date: Tue, 23 Jun 2009 10:01:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2136) Simple match rule
 fails on 5.0.1 and works on 4.0.7
In-Reply-To: <17964558.1245745317053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11077436.1245765717348.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Corneil du Plessis updated JBRULES-2136:
----------------------------------------

    Priority: Critical  (was: Major)


> Simple match rule fails on 5.0.1 and works on 4.0.7
> ---------------------------------------------------
>
>                 Key: JBRULES-2136
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2136
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Corneil du Plessis
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: drools-test.zip
>
>
> A simple rule that worked in 4.0.7 fails in 5.0.1
> An Eclipse project to illustrate the problem will be attached to this issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:21:56 2009
From: jira-events at lists.jboss.org (Jay Balunas (JIRA))
Date: Tue, 23 Jun 2009 10:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-5615) Synchronization
 mutex for clustered environments
In-Reply-To: <31351334.1213134137427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33215073.1245766916855.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Balunas reassigned JBAS-5615:
---------------------------------

    Assignee: Scott Marlow


Spoke with Scott Marlow who had some thought on the issue, and will comment.

> Synchronization mutex for clustered environments
> ------------------------------------------------
>
>                 Key: JBAS-5615
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5615
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: Nick Belaevski
>            Assignee: Scott Marlow
>            Priority: Minor
>
> Quote from http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136590 : "they'll need to be thread safe or have access to them synchronized".
> There's no object to synchronize against: SessionBasedClusteredSession doesn synchronization against itself:
>    public void writeExternal(ObjectOutput out) throws IOException
>    {
>       synchronized (this)
>       {
>          ...
>      }   
>    
>    } 
> but application developers see the wrapped one (instance of StandardSessionFacade), so synchronizing against session object does not prevent from concurrency errors

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:25:56 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Tue, 23 Jun 2009 10:25:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7047) Deployers hide
 exception cause stack
Message-ID: <6579847.1245767156834.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deployers hide exception cause stack
------------------------------------

                 Key: JBAS-7047
                 URL: https://jira.jboss.org/jira/browse/JBAS-7047
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Pete Muir




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:25:57 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Tue, 23 Jun 2009 10:25:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7047) Deployers hide
 exception cause stack
In-Reply-To: <6579847.1245767156834.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32302413.1245767157970.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pete Muir updated JBAS-7047:
----------------------------

    Description: Currently the deployers unwrap all deployment exceptions to the root cause, and store in incompleteDeployments. This means we can't check for exception wrapping


> Deployers hide exception cause stack
> ------------------------------------
>
>                 Key: JBAS-7047
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7047
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Pete Muir
>
> Currently the deployers unwrap all deployment exceptions to the root cause, and store in incompleteDeployments. This means we can't check for exception wrapping

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:29:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 23 Jun 2009 10:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1850) Synchronizations
 registered on the tx depend on ordering
In-Reply-To: <4600779.1245147596442.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7088418.1245767396715.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated EJBTHREE-1850:
------------------------------------

      Component/s: core
    Fix Version/s: 1.1.8
                       (was: EAP 5)


> Synchronizations registered on the tx depend on ordering
> --------------------------------------------------------
>
>                 Key: EJBTHREE-1850
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1850
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: 1.1.8
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:31:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 23 Jun 2009 10:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1850)
 Synchronizations registered on the tx depend on ordering
In-Reply-To: <4600779.1245147596442.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27914075.1245767516848.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved EJBTHREE-1850.
-------------------------------------

    Resolution: Done


Synchronizations are now managed within StatefulBeanContext.

> Synchronizations registered on the tx depend on ordering
> --------------------------------------------------------
>
>                 Key: EJBTHREE-1850
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1850
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: 1.1.8
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:32:00 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 23 Jun 2009 10:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-898) Logging stays
 silent when a RuntimeException is thrown from preDestroy method
In-Reply-To: <32474345.1172739140007.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8119608.1245767520077.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved EJBTHREE-898.
------------------------------------

    Resolution: Done
      Assignee: Carlo de Wolf


The code in EJBTHREE-1850 does additional logging when something fails in beforeCompletion or afterCompletion.

> Logging stays silent when a RuntimeException is thrown from preDestroy method
> -----------------------------------------------------------------------------
>
>                 Key: EJBTHREE-898
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-898
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: Branch_4_2
>
>
> 09:48:47,432 INFO  [STDOUT] ContainedBean.preDestroy
> 09:48:47,432 WARN  [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator_4] TwoPhaseCoordinator.afterCompletion - returned failure for com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple at 1ccc3ea

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:32:01 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 23 Jun 2009 10:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-898) Logging stays
 silent when a RuntimeException is thrown from preDestroy method
In-Reply-To: <32474345.1172739140007.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9242749.1245767521033.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated EJBTHREE-898:
-----------------------------------

    Fix Version/s: 1.1.8
                       (was: Branch_4_2)


> Logging stays silent when a RuntimeException is thrown from preDestroy method
> -----------------------------------------------------------------------------
>
>                 Key: EJBTHREE-898
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-898
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: 1.1.8
>
>
> 09:48:47,432 INFO  [STDOUT] ContainedBean.preDestroy
> 09:48:47,432 WARN  [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator_4] TwoPhaseCoordinator.afterCompletion - returned failure for com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple at 1ccc3ea

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 10:35:58 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 23 Jun 2009 10:35:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1854) Configure EJB3
 MC beans to avoid AOPDependencyBuilder
Message-ID: <16175879.1245767758566.JavaMail.jira@cloud.prod.atl2.jboss.com>

Configure EJB3 MC beans to avoid AOPDependencyBuilder
-----------------------------------------------------

                 Key: EJBTHREE-1854
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1854
             Project: EJB 3.0
          Issue Type: Task
          Components: core, deployers
    Affects Versions: 1.1.7
            Reporter: jaikiran pai
            Assignee: jaikiran pai


This task is to keep track of the change(s) required for all EJB3 MC bean (programatic and xml based) to ensure that the AOPDependencyBuilder does not come into picture during deployment. Avoiding AOPDependencyBuilder has shown good performance improvements.

There isn't a final decision yet on how to do this although MC provides @DisableAOP annotation to achieve this. The MC support for this is currently available in AS 5_x branch and needs to be ported to AS trunk before EJB3 can think of using this. Once there's a decision on what's the best approach to accomplish this, we can do the changes in EJB3.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 11:16:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 23 Jun 2009 11:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1437) Browsers
 should iterate on queue
In-Reply-To: <33355941.1225819521109.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15335449.1245770216703.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated JBMESSAGING-1437:
-------------------------------------

    Attachment: patch-JBMESSAGING-1437.txt


strike 2!

this patch is more correct wrt to promptDelivery and credit flow control.

however, it still does not work with large messages at the moment.

> Browsers should iterate on queue
> --------------------------------
>
>                 Key: JBMESSAGING-1437
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1437
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>         Attachments: patch-JBMESSAGING-1437.txt
>
>
> Currently the server browser implementation is taking a snapshot of the queue and browsing that. Instead we should implement an iterator on the queue which allows refs to be added or removed from the ends without affecting it.
> This is also necessary to allow failover for browsers which is very hard to implement with the current snapshot approach

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 11:16:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 23 Jun 2009 11:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1437) Browsers
 should iterate on queue
In-Reply-To: <33355941.1225819521109.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26733170.1245770216915.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated JBMESSAGING-1437:
-------------------------------------

    Attachment:     (was: patch-JBMESSAGING-1437.txt)


> Browsers should iterate on queue
> --------------------------------
>
>                 Key: JBMESSAGING-1437
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1437
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>         Attachments: patch-JBMESSAGING-1437.txt
>
>
> Currently the server browser implementation is taking a snapshot of the queue and browsing that. Instead we should implement an iterator on the queue which allows refs to be added or removed from the ends without affecting it.
> This is also necessary to allow failover for browsers which is very hard to implement with the current snapshot approach

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 11:42:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jun 2009 11:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7048) Switch HAPartition to
 LongRunningTasksThreadPool
Message-ID: <20000345.1245771776621.JavaMail.jira@cloud.prod.atl2.jboss.com>

Switch HAPartition to LongRunningTasksThreadPool
------------------------------------------------

                 Key: JBAS-7048
                 URL: https://jira.jboss.org/jira/browse/JBAS-7048
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-6.0.0.Alpha1


Now uses "ThreadPool" but for a long running task.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 11:44:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 23 Jun 2009 11:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1851) Investigate
 the failure
 org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
In-Reply-To: <10648726.1245161216783.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <812217.1245771896796.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473465#action_12473465 ] 

jaikiran pai commented on EJBTHREE-1851:
----------------------------------------

This testcase deploys multiple deployments and some deployments have the same bean names. The EJB3MetricsDeployer currently deploys MC beans based on the EJB names:

2009-06-23 21:00:30,589 DEBUG [org.jboss.ejb3.metrics.deployer.Ejb3MetricsDeployer] (RMI TCP Connection(10)-127.0.0.1) Attaching MC Bean with name "StatelessBean" ....

This can lead to duplicate binding exceptions if there are multiple deployments containing the same EJB names:

2009-06-23 21:00:39,736 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (RMI TCP Connection(10)-127.0.0.1) Error installing to Real: name=vfszip:/path/target/test-lib/stateful-test.jar/ state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying: StatelessBean
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:125)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java: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:1632)
	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.deployment.MainDeployer.deploy(MainDeployer.java:831)
	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:605)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.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 sun.reflect.GeneratedMethodAccessor333.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
	at sun.reflect.GeneratedMethodAccessor323.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
	at sun.reflect.GeneratedMethodAccessor322.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
	at sun.reflect.GeneratedMethodAccessor321.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
	at sun.rmi.transport.Transport$1.run(Transport.java:153)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
	at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalStateException: StatelessBean is already installed.
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
	... 65 more


The EJB3MetricsDeployer could be changed to deploy MC beans with names that include even the deployment name, which contains the EJB.

> Investigate the failure org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
> -------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1851
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1851
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: testsuite
>    Affects Versions: 1.1.7
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> The org.jboss.ejb3.test.container.unit.ContainerTestCase consistently fails with:
> javax.naming.NameNotFoundException: Stateful not bound
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
> 	at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
> 	at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> 	at java.lang.Thread.run(Thread.java:595)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> 	at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at org.jboss.ejb3.test.container.unit.ContainerTestCase.testInvocationStatistics(ContainerTestCase.java:93)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
> 	at junit.extensions.TestSetup.run(TestSetup.java:27)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 13:30:09 2009
From: jira-events at lists.jboss.org (Sachin Chandradethan (JIRA))
Date: Tue, 23 Jun 2009 13:30:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1665) Unable to
 create durable queues using adminstered object(JMX)
Message-ID: <13778345.1245778209824.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unable to create durable queues using adminstered object(JMX)
-------------------------------------------------------------

                 Key: JBMESSAGING-1665
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1665
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 2.0.0.beta3
         Environment: OS: Windows Vista. JDK 1.6
            Reporter: Sachin Chandradethan
            Assignee: Tim Fox


 I tried to create queues in dynamically using JMX Administered Objects.  I could create the queues successfully. But once  messaging server is shutdown, the queues are disappeared. I tried to create the queues using JConsole also. Same thing is happening there also. The queues were disappeared once the server is restarted.

 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 13:49:57 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jun 2009 13:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7015) AS JChannelFactory
 should always add singleton_name
In-Reply-To: <10577550.1244837396926.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21290288.1245779397154.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated JBAS-7015:
-----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                       (was: JBossAS-6.0.0.Alpha1)


> AS JChannelFactory should always add singleton_name
> ---------------------------------------------------
>
>                 Key: JBAS-7015
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7015
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Currently it only adds a singleton_name if channel is requested via createMultiplexerChannel() methods, not for createChannel(String stack). But the latter will possibly become the default, and if two services request channels from the same stack and there is no singleton_name, there will be conflicts. The AS should use a shared transport whenever possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 13:49:57 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jun 2009 13:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7009) AS JChannelFactory
 shouldn't subclass the JGroups version
In-Reply-To: <14168838.1244666337520.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15690516.1245779397316.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated JBAS-7009:
-----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                       (was: JBossAS-6.0.0.Alpha1)


> AS JChannelFactory shouldn't subclass the JGroups version
> ---------------------------------------------------------
>
>                 Key: JBAS-7009
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7009
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The AS JChannelFactory class started off as a subclass of the JGroups version with a few small differences. Over time it has added a lot of specialized behavior, and exposing a full-featured ManagedObject interface requires adding significantly more. At this point the benefits of subclassing don't justify the hassle of keeping them coupled.
> Both implement the ChannelFactory interface, which is the client view.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 13:55:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jun 2009 13:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7009) AS JChannelFactory
 shouldn't subclass the JGroups version
In-Reply-To: <14168838.1244666337520.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15744117.1245779756962.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7009.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> AS JChannelFactory shouldn't subclass the JGroups version
> ---------------------------------------------------------
>
>                 Key: JBAS-7009
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7009
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The AS JChannelFactory class started off as a subclass of the JGroups version with a few small differences. Over time it has added a lot of specialized behavior, and exposing a full-featured ManagedObject interface requires adding significantly more. At this point the benefits of subclassing don't justify the hassle of keeping them coupled.
> Both implement the ChannelFactory interface, which is the client view.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 13:57:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jun 2009 13:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7014) JChannelFactory
 addSingletonName handling broken
In-Reply-To: <26543394.1244836196419.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31583178.1245779876559.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7014.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> JChannelFactory addSingletonName handling broken
> ------------------------------------------------
>
>                 Key: JBAS-7014
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7014
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-5.1.0.CR1, JBossAS-5.1.0.GA
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The expected path for the AS JChannelFactory's addSingletonName logic is broken -- it thinks it is mutating the passed in config but it isn't.
> Luckily this is minor because there's separate logic that executes when JGroups throws an UnsupportedOperationException -- said logic works correctly and JGroups always throws the exception. But if a later release of JGroups fixed the UOE, this bug would be exposed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 13:57:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jun 2009 13:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7015) AS JChannelFactory
 should always add singleton_name
In-Reply-To: <10577550.1244837396926.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24464724.1245779876697.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7015.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> AS JChannelFactory should always add singleton_name
> ---------------------------------------------------
>
>                 Key: JBAS-7015
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7015
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Currently it only adds a singleton_name if channel is requested via createMultiplexerChannel() methods, not for createChannel(String stack). But the latter will possibly become the default, and if two services request channels from the same stack and there is no singleton_name, there will be conflicts. The AS should use a shared transport whenever possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 13:57:56 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jun 2009 13:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7016) Management interface
 for JChannelFactory
In-Reply-To: <9111063.1244840876545.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30947091.1245779876827.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7016.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> Management interface for JChannelFactory
> ----------------------------------------
>
>                 Key: JBAS-7016
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7016
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 14:15:57 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 23 Jun 2009 14:15:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7035) Help avoid unneeded
 scanning of classes for annotations by adding jboss-scanning.xml
In-Reply-To: <32851153.1245270596605.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33111965.1245780957695.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated JBAS-7035:
-------------------------------

    Description: 
Please add the attached jboss-scanning.xml file to folders:
  jbossws.sar/jbossws-management.war/META-INF
  jbossws.sar/jbossws-management.war/WEB-INF
  juddi-service.sar/META-INF
  juddi.war/WEB-INF

  was:
Please add the attached jboss-scanning.xml file to folders:
  jbossws.sar/jbossws-management.war/META-INF
  jbossws.sar/jbossws-management.war/WEB-INF




> Help avoid unneeded scanning of classes for annotations by adding jboss-scanning.xml
> ------------------------------------------------------------------------------------
>
>                 Key: JBAS-7035
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7035
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott Marlow
>            Assignee: Alessio Soldano
>             Fix For: JBossAS-6.0.0.Alpha1
>
>         Attachments: jboss-scanning.xml
>
>
> Please add the attached jboss-scanning.xml file to folders:
>   jbossws.sar/jbossws-management.war/META-INF
>   jbossws.sar/jbossws-management.war/WEB-INF
>   juddi-service.sar/META-INF
>   juddi.war/WEB-INF

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 14:26:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 23 Jun 2009 14:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
Message-ID: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>

tests-jacc-securitymgr test server fails to start with OpenJDK 6
----------------------------------------------------------------

                 Key: JBAS-7049
                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
            Reporter: Shelly McGowan
            Assignee: Anil Saldhana
             Fix For: JBossAS-5.2.0.Beta1


This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 14:26:56 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Tue, 23 Jun 2009 14:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-7050) Unable to create any
 kind of datasource or connection factory
Message-ID: <32284770.1245781616843.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch moved JOPR-236 to JBAS-7050:
-------------------------------------------

              Project: JBoss Application Server  (was: Jopr)
                  Key: JBAS-7050  (was: JOPR-236)
          Component/s:     (was: Plugin - JBoss AS 5)
        Fix Version/s: JBossAS-5.2.0.Beta1
                           (was: 2.3)
    Affects Version/s: JBossAS-5.1.0.GA
                           (was: 2.3)
             Security: Public


> Unable to create any kind of datasource or connection factory
> -------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 14:30:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 23 Jun 2009 14:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22496903.1245781856503.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7049:
---------------------------------

    Attachment: boot.log
                error.log
                output.log


Logs attached.
CI test runs can be seen here:
http://hudson.qa.jboss.com/hudson/view/JBoss AS/job/JBoss-AS-5.1.x-testSuite-openjdk6

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 14:48:56 2009
From: jira-events at lists.jboss.org (Jay Balunas (JIRA))
Date: Tue, 23 Jun 2009 14:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-5615) Synchronization
 mutex for clustered environments
In-Reply-To: <31351334.1213134137427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28442019.1245782936606.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473496#action_12473496 ] 

Jay Balunas commented on JBAS-5615:
-----------------------------------

Scott added comments to the forum post listed above for more information.  Not sure if Nick is monitoring, so a comment here should email Nick on it.

> Synchronization mutex for clustered environments
> ------------------------------------------------
>
>                 Key: JBAS-5615
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5615
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: Nick Belaevski
>            Assignee: Scott Marlow
>            Priority: Minor
>
> Quote from http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136590 : "they'll need to be thread safe or have access to them synchronized".
> There's no object to synchronize against: SessionBasedClusteredSession doesn synchronization against itself:
>    public void writeExternal(ObjectOutput out) throws IOException
>    {
>       synchronized (this)
>       {
>          ...
>      }   
>    
>    } 
> but application developers see the wrapped one (instance of StandardSessionFacade), so synchronizing against session object does not prevent from concurrency errors

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 15:26:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 23 Jun 2009 15:26:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1665) Unable to
 create durable queues using adminstered object(JMX)
In-Reply-To: <13778345.1245778209824.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4445476.1245785217008.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473504#action_12473504 ] 

Tim Fox commented on JBMESSAGING-1665:
--------------------------------------

Sachin-

I think you'll find the JMS queues have not disappeared - try producer/consuming from them.

The queues will still exist even though they are not in JNDI/registered in management.

Only JMS queues that are explicitly declared in jbm-jms.xml will be loaded into JNDI/management on startup

> Unable to create durable queues using adminstered object(JMX)
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1665
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1665
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 2.0.0.beta3
>         Environment: OS: Windows Vista. JDK 1.6
>            Reporter: Sachin Chandradethan
>            Assignee: Tim Fox
>
>  I tried to create queues in dynamically using JMX Administered Objects.  I could create the queues successfully. But once  messaging server is shutdown, the queues are disappeared. I tried to create the queues using JConsole also. Same thing is happening there also. The queues were disappeared once the server is restarted.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 16:04:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Tue, 23 Jun 2009 16:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
Message-ID: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>

ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
--------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7051
                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Scott M Stark
             Fix For: JBossAS-5.2.0.Beta1


This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:

1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.

2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:

container=JBossMQ|JBossMessaging

which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.


Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:

15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
rvice=Queue, parent=JBoss EAP 5 (default)]
org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
        at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
        at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
rceManager.java:235)
        at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
figurationUIBean.java:144)
        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.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
        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.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.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
tion(ResourceConfigurationUIBean_$$_javassist_12.java)
        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.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
        at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
        at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
        at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
        at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
        at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
        at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
        at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
        at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
        at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
        at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
        at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
        at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
        at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
        at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
        at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
        at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
        at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
        at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
        at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
        at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        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:235)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
a:126)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
:70)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
        ... 84 more


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 16:12:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 23 Jun 2009 16:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2133) Drools-solver
 manual corrections from Yet another math programming consultant blog
In-Reply-To: <15744621.1245657057041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6922321.1245787976933.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473511#action_12473511 ] 

Geoffrey De Smet commented on JBRULES-2133:
-------------------------------------------

fixed in subversion

> Drools-solver manual corrections from Yet another math programming consultant blog
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2133
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2133
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Optional
>             Fix For: 5.1.0.M1
>
>
> http://yetanothermathprogrammingconsultant.blogspot.com/2009/06/simplex-method-description.html?showComment=1245656649020#c9186233704679009828
> - The branch&bound section should mention about the unique feature that it provides bounds and hence an indication of the quality of the solution.
> - The simplex  section is supposedly wrong (It's unclear how it can be corrected): "If the word Simplex was missing I would not recognize this is about the Simplex method. One big equation? (No word about not being suited to handle discrete variables)."
> - "Local search starts from an initial solution and evolves that single solution into a better and better solution." should be "Local search starts from an initial solution and evolves that single solution, ussually into a better and better solution."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 16:12:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 23 Jun 2009 16:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2133) Drools-solver
 manual corrections from Yet another math programming consultant blog
In-Reply-To: <15744621.1245657057041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24224762.1245787976792.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet resolved JBRULES-2133.
---------------------------------------

    Fix Version/s: 5.1.0.M1
       Resolution: Done


> Drools-solver manual corrections from Yet another math programming consultant blog
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2133
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2133
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Optional
>             Fix For: 5.1.0.M1
>
>
> http://yetanothermathprogrammingconsultant.blogspot.com/2009/06/simplex-method-description.html?showComment=1245656649020#c9186233704679009828
> - The branch&bound section should mention about the unique feature that it provides bounds and hence an indication of the quality of the solution.
> - The simplex  section is supposedly wrong (It's unclear how it can be corrected): "If the word Simplex was missing I would not recognize this is about the Simplex method. One big equation? (No word about not being suited to handle discrete variables)."
> - "Local search starts from an initial solution and evolves that single solution into a better and better solution." should be "Local search starts from an initial solution and evolves that single solution, ussually into a better and better solution."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 16:12:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Tue, 23 Jun 2009 16:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <669170.1245787976661.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7051:
-------------------------------

    Attachment: jboss-ejb3-tutorial-mdb.jar


The attached EJB-JAR contains a couple JBossMQ queues that can be used to demonstrate this issue. Deploy it to an EAP5 instance and then in the Admin Console go to the Configuration tabs of one of the below Queue Resources:

jboss.mq.destination:name=tutorial,service=Queue 
jboss.mq.destination:name=defaultedtutorial,service=Queue 

You'll see the 'serverPeer' CCE in the server log.


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         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.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         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.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.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         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.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 16:39:56 2009
From: jira-events at lists.jboss.org (Nick Belaevski (JIRA))
Date: Tue, 23 Jun 2009 16:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-5615) Synchronization
 mutex for clustered environments
In-Reply-To: <31351334.1213134137427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13796112.1245789596576.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473514#action_12473514 ] 

Nick Belaevski commented on JBAS-5615:
--------------------------------------

Thanks, Jay! 

I've posted information I have on forum.

> Synchronization mutex for clustered environments
> ------------------------------------------------
>
>                 Key: JBAS-5615
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5615
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: Nick Belaevski
>            Assignee: Scott Marlow
>            Priority: Minor
>
> Quote from http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136590 : "they'll need to be thread safe or have access to them synchronized".
> There's no object to synchronize against: SessionBasedClusteredSession doesn synchronization against itself:
>    public void writeExternal(ObjectOutput out) throws IOException
>    {
>       synchronized (this)
>       {
>          ...
>      }   
>    
>    } 
> but application developers see the wrapped one (instance of StandardSessionFacade), so synchronizing against session object does not prevent from concurrency errors

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 17:18:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Tue, 23 Jun 2009 17:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7052) when invoked from
 remote client, 
 call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
Message-ID: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>

when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7052
                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Scott M Stark
            Priority: Critical
             Fix For: JBossAS-5.2.0.Beta1


The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.

To reproduce this, the following client code can be used:
https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/

Just do:
mvn install
cd target
java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar

Here's the stack trace:

Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
        at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
        at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
        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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.HashSet.readObject(HashSet.java:291)
        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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.HashSet.readObject(HashSet.java:291)
        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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
        at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
        at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
        at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 17:54:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 23 Jun 2009 17:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2137) Expose
 insertLogical() method into the RuleContext interface
Message-ID: <31462917.1245794096471.JavaMail.jira@cloud.prod.atl2.jboss.com>

Expose insertLogical() method into the RuleContext interface
------------------------------------------------------------

                 Key: JBRULES-2137
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2137
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


Expose insertLogical() method into the RuleContext interface

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 17:58:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 23 Jun 2009 17:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2137) Expose
 insertLogical() method into the RuleContext interface
In-Reply-To: <31462917.1245794096471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14753642.1245794336423.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2137.
----------------------------------

    Resolution: Done


> Expose insertLogical() method into the RuleContext interface
> ------------------------------------------------------------
>
>                 Key: JBRULES-2137
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2137
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> Expose insertLogical() method into the RuleContext interface

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 18:31:56 2009
From: jira-events at lists.jboss.org (Michal Bali (JIRA))
Date: Tue, 23 Jun 2009 18:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2138) RuleContext and
 insertLogical()
Message-ID: <13473430.1245796316751.JavaMail.jira@cloud.prod.atl2.jboss.com>

RuleContext and insertLogical()
-------------------------------

                 Key: JBRULES-2138
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2138
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-api
    Affects Versions: 5.0.1.FINAL
            Reporter: Michal Bali
            Assignee: Mark Proctor
             Fix For: 5.1.0.M1


The org.drools.runtime.rule.RuleContext doesn't support insertLogical() as did the deprecated KnowledgeHelper. Please add this method to RuleContext.

Thank you.
Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 18:31:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Tue, 23 Jun 2009 18:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7052) when invoked from
 remote client, 
 call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2315860.1245796316594.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7052:
-------------------------------

    Priority: Blocker  (was: Critical)


Raising to Blocker, since this is causing a bunch of stuff to break when running the jbas5 plugin within the Enterprise Jopr Agent.


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 18:35:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Tue, 23 Jun 2009 18:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7314930.1245796556625.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473523#action_12473523 ] 

Ian Springer commented on JBAS-7052:
------------------------------------

I also see a CNFE for ManagedComponentDelegate, another profileservice impl class, which also occurs on calls to getComponentsForType(). Here's the stack trace from the Jopr jbas5 plugin:

2009-06-23 18:26:08,298 ERROR [ResourceContainer.invoker.daemon-11] (org.rhq.plugins.jbossas5.ApplicationServerComponent)- Failed to obtain metric 'MCBean|JTA|*|commitCount'.
java.lang.IllegalStateException: java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedComponentDelegate
	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:165)
	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:67)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:250)
	at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedComponentDelegate
	at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
	at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
	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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
	at java.util.HashSet.readObject(HashSet.java:291)
	at sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
	at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
	at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
	at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:161)
	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getSingletonManagedComponent(ManagedComponentUtils.java:67)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.getValues(ApplicationServerComponent.java:250)
	at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)
	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
	at org.rhq.plugins.jbossas5.util.ManagedComponentUtils.getManagedComponents(ManagedComponentUtils.java:161)
	... 11 more


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 18:55:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 23 Jun 2009 18:55:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2138) RuleContext and
 insertLogical()
In-Reply-To: <13473430.1245796316751.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21531529.1245797757076.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned JBRULES-2138:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> RuleContext and insertLogical()
> -------------------------------
>
>                 Key: JBRULES-2138
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2138
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-api
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Michal Bali
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> The org.drools.runtime.rule.RuleContext doesn't support insertLogical() as did the deprecated KnowledgeHelper. Please add this method to RuleContext.
> Thank you.
> Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 18:55:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 23 Jun 2009 18:55:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2138) RuleContext and
	insertLogical()
In-Reply-To: <13473430.1245796316751.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4095130.1245797757247.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2138.
----------------------------------

    Resolution: Done


> RuleContext and insertLogical()
> -------------------------------
>
>                 Key: JBRULES-2138
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2138
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-api
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Michal Bali
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> The org.drools.runtime.rule.RuleContext doesn't support insertLogical() as did the deprecated KnowledgeHelper. Please add this method to RuleContext.
> Thank you.
> Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 22:40:09 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 23 Jun 2009 22:40:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6889) tests in
 tests-aop-scoped failing with IBM JDK
In-Reply-To: <7099808.1242045886541.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26956651.1245811209744.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6889:
---------------------------------


Correction to above comment:  results after upgrading to JBoss AOP 2.1.2.GA in my local workspace.

> tests in tests-aop-scoped failing with IBM JDK
> ----------------------------------------------
>
>                 Key: JBAS-6889
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6889
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: TEST-org.jboss.test.aop.test.ScopedAnnotatedTestCase-aop-scoped.xml
>
>
> Tests in the tests-aop-scoped target of JBoss AS testsuite are failing.
> The tests are:
> org.jboss.test.aop.test.ScopedAnnotatedTestCase
> org.jboss.test.aop.test.ScopedAttachUnitTestCase
> org.jboss.test.aop.test.ScopedEarWithClassesInWebInfTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseLoadedScopedNoParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseLoadedScopedParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseNotLoadedScopedNoParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseNotLoadedScopedParentDelegationTestCase
> org.jboss.test.aop.test.ScopedUnitTestCase
> org.jboss.test.aop.test.ScopedWovenDependencyTestCase
> The error message is:
> javax.management.RuntimeErrorException
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:182)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: java.lang.ExceptionInInitializerError
> 	at java.lang.J9VMInternals.initialize(J9VMInternals.java:216)
> 	at org.jboss.test.aop.jdk15annotated.ScopedAnnotatedTester.testBinding(ScopedAnnotatedTester.java:50)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.aop.Domain$1.run(Domain.java:124)
> 	at org.jboss.aop.Domain$1.run(Domain.java:121)
> 	at java.security.AccessController.doPrivileged(AccessController.java:197)
> 	at org.jboss.aop.Domain.getDomainName(Domain.java:119)
> 	at org.jboss.test.aop.jdk15annotated.POJO$POJOAdvisor.initialise(POJO$POJOAdvisor.java)
> 	at org.jboss.test.aop.jdk15annotated.POJO$POJOAdvisor.<init>(POJO$POJOAdvisor.java)
> 	at org.jboss.test.aop.jdk15annotated.POJO.<clinit>(POJO.java)
> 	at java.lang.J9VMInternals.initializeImpl(Native Method)
> 	at java.lang.J9VMInternals.initialize(J9VMInternals.java:194)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 22:51:14 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 23 Jun 2009 22:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-214) fix matadata common
	build
Message-ID: <26514201.1245811874997.JavaMail.jira@cloud.prod.atl2.jboss.com>

fix matadata common build
-------------------------

                 Key: JBMETA-214
                 URL: https://jira.jboss.org/jira/browse/JBMETA-214
             Project: JBoss Metadata
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.2.Beta2


compile matadata/common in JDK5 will be failed

[INFO] [compiler:compile]
[INFO] Compiling 182 source files to /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/target/classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure

/home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[29,20] package javax.xml.ws does not exist

/home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/WebServiceHandlerChainProcessor.java:[34,17] package javax.jws does not exist

/home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[70,69] cannot find symbol
symbol  : class WebServiceRef
location: class org.jboss.metadata.annotation.creator.ws.AbstractWebServiceRefProcessor<E>

/home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[99,55] cannot find symbol
symbol  : class WebServiceRef
location: class org.jboss.metadata.annotation.creator.ws.AbstractWebServiceRefProcessor<E>

.....


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 23:04:56 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Tue, 23 Jun 2009 23:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <8305115.1245812696549.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473536#action_12473536 ] 

John Ament commented on JBAS-7032:
----------------------------------

I'm able to reproduce in a number of environments.

Personal PC (work).  Dell optiplex gx745. 2gb ram.
IBM x 336 in clustered mode
Personal laptop, dell studio 1537

work pc is opensuse 11.1 + 64 bit.  2gb ram.
laptop's windows 7 + 64bit. 4gb ram.
336's are 64 bit, jdk 6.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 23 23:08:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 23 Jun 2009 23:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-214) fix matadata
	common build
In-Reply-To: <26514201.1245811874997.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1677496.1245812936452.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBMETA-214.
-------------------------------

    Resolution: Done


> fix matadata common build
> -------------------------
>
>                 Key: JBMETA-214
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-214
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.2.Beta2
>
>
> compile matadata/common in JDK5 will be failed
> [INFO] [compiler:compile]
> [INFO] Compiling 182 source files to /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/target/classes
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Compilation failure
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[29,20] package javax.xml.ws does not exist
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/WebServiceHandlerChainProcessor.java:[34,17] package javax.jws does not exist
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[70,69] cannot find symbol
> symbol  : class WebServiceRef
> location: class org.jboss.metadata.annotation.creator.ws.AbstractWebServiceRefProcessor<E>
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[99,55] cannot find symbol
> symbol  : class WebServiceRef
> location: class org.jboss.metadata.annotation.creator.ws.AbstractWebServiceRefProcessor<E>
> .....

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 00:16:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 24 Jun 2009 00:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <25153643.1245817016723.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7032:
---------------------------------


And your JBoss AS installation was from the distributed jboss-5.1.0.GA-jdk6.zip?

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 00:19:08 2009
From: jira-events at lists.jboss.org (Sachin Chandradethan (JIRA))
Date: Wed, 24 Jun 2009 00:19:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1665) Unable to
 create durable queues using adminstered object(JMX)
In-Reply-To: <13778345.1245778209824.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18112747.1245817148685.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sachin Chandradethan closed JBMESSAGING-1665.
---------------------------------------------

    Resolution: Done


Thanks Tim. Its working fine.

> Unable to create durable queues using adminstered object(JMX)
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1665
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1665
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 2.0.0.beta3
>         Environment: OS: Windows Vista. JDK 1.6
>            Reporter: Sachin Chandradethan
>            Assignee: Tim Fox
>
>  I tried to create queues in dynamically using JMX Administered Objects.  I could create the queues successfully. But once  messaging server is shutdown, the queues are disappeared. I tried to create the queues using JConsole also. Same thing is happening there also. The queues were disappeared once the server is restarted.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 02:38:57 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Wed, 24 Jun 2009 02:38:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1666) Add
 "messageCount" attribute on Address MBean
Message-ID: <18851986.1245825537257.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add "messageCount" attribute on Address MBean
---------------------------------------------

                 Key: JBMESSAGING-1666
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1666
             Project: JBoss Messaging
          Issue Type: Feature Request
            Reporter: Bijith Kumar
            Assignee: Tim Fox


Value shown in "messageCount" attribute of a queue MBean does not include the number of messages that are paged. This is because messages are paged to disk  before they are routed in the postoffice. So, for the user to be able to find the total number of messages that are added to a queue, Tim suggested that, we add a "messageCount" attribute to the Address MBean. That would indicate how many messages are paged for a particular destination address.  Please refer http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157325 for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 03:33:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 24 Jun 2009 03:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1855) Switch to
 ejb3-core 1.1.8-SNAPSHOT
Message-ID: <27800202.1245828836468.JavaMail.jira@cloud.prod.atl2.jboss.com>

Switch to ejb3-core 1.1.8-SNAPSHOT
----------------------------------

                 Key: EJBTHREE-1855
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1855
             Project: EJB 3.0
          Issue Type: Task
          Components: as-int, ejb3
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf
             Fix For: 1.1.8




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 03:35:56 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 24 Jun 2009 03:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1855) Switch to
 ejb3-core 1.1.8-SNAPSHOT
In-Reply-To: <27800202.1245828836468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31576970.1245828956442.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved EJBTHREE-1855.
-------------------------------------

    Resolution: Done


> Switch to ejb3-core 1.1.8-SNAPSHOT
> ----------------------------------
>
>                 Key: EJBTHREE-1855
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1855
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: as-int, ejb3
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.8
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 05:24:56 2009
From: jira-events at lists.jboss.org (Toni Rikkola (JIRA))
Date: Wed, 24 Jun 2009 05:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1365) [M]Importing a drl
 with no package statement fails
In-Reply-To: <11983213.1196989342536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1796880.1245835496819.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toni Rikkola closed JBRULES-1365.
---------------------------------

    Resolution: Done


If there is no name for the package Guvnor now asks for one.

> [M]Importing a drl with no package statement fails
> --------------------------------------------------
>
>                 Key: JBRULES-1365
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1365
>             Project: JBoss Drools
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 4.0.3
>            Reporter: Michael Neale
>            Assignee: Toni Rikkola
>             Fix For: 5.1.0.M1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 05:30:56 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Wed, 24 Jun 2009 05:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-20) JDK loggign
 isLoggable(Level.FINEST) returns false with Log4J backend
Message-ID: <12251162.1245835856606.JavaMail.jira@cloud.prod.atl2.jboss.com>

JDK loggign isLoggable(Level.FINEST) returns false with Log4J backend
---------------------------------------------------------------------

                 Key: JBLOGGING-20
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-20
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-logbridge
         Environment: JBoss 5.1.0, JDK 1.6u13
            Reporter: Ondrej Medek
            Assignee: Dimitris Andreadis


I have code using JDK logging like:

if (LOG.isLoggable(Level.FINEST)) {
  LOG.finest("added into list: " + something);
}

I have no log. When I use just

LOG.finest("added into list: " + something);

I got a log in the log file.

I use JBoss with Log4J. It is configured to log ALL stuff.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 06:26:56 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Wed, 24 Jun 2009 06:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <2453923.1245839216539.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473577#action_12473577 ] 

John Ament commented on JBAS-7032:
----------------------------------

Yes sorry, all are 5.1 JDK6 GA.  Also, it appears to work correctly in 5.1 CR1.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 08:41:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 24 Jun 2009 08:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30254153.1245847316548.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473596#action_12473596 ] 

Alexey Loubyansky commented on JBXB-206:
----------------------------------------

So, the most time consuming is org.jboss.xb.binding.Util#loadSchema(java.io.InputStream, String, org.jboss.xb.binding.sunday.unmarshalling.SchemaBindingResolver). I wonder why it is called at all. It's supposed to be called only from XsdBinder. Which shouldn't be used in your case. We need to debug and see what's triggering that.

> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>         Attachments: jboss-profiler.properties, jbossxb.zip, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 08:46:57 2009
From: jira-events at lists.jboss.org (Naresh Bhatia (JIRA))
Date: Wed, 24 Jun 2009 08:46:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBVFS-109) Trying to access
 all classpath
 resources from a web application fails due to VFS errors
In-Reply-To: <14030842.1241499346657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3071915.1245847617081.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBVFS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473597#action_12473597 ] 

Naresh Bhatia commented on JBVFS-109:
-------------------------------------

Did this fix get into JBoss 5.1.0.GA? I am using JBoss 5.1.0.GA with a Spring application that uses classpath scanning (using <context:component-scan>) fails with the following error:

[org.springframework.core.io.support.PathMatchingResourcePatternResolver]
Cannot search for matching files underneath URL
[vfszip:/D:/jboss-5.1.0/server/default-with-jbm2/deploy/myapp.war/WEB-INF/lib/mylistener-1.0-SNAPSHOT.jar/myapp/mylistener/]
because it does not correspond to a directory in the file system

> Trying to access all classpath resources from a web application fails due to VFS errors
> ---------------------------------------------------------------------------------------
>
>                 Key: JBVFS-109
>                 URL: https://jira.jboss.org/jira/browse/JBVFS-109
>             Project: JBoss VFS
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>            Reporter: Marius Bogoevici
>            Assignee: Ales Justin
>             Fix For: 2.1.2.GA
>
>         Attachments: spring-jboss-jaxws.tar.gz
>
>
> The error has been triggered by using classpath scanning in Spring, but can be reproduced independently.
> The code in the servlet listed below does virtually the same thing as the VFSResourcePatternResolver:
> public class BasicServlet extends HttpServlet{
>     @Override
>     protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
>         ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
>         Enumeration<URL> urls = classLoader.getResources("");
>         StringBuffer buffer = new StringBuffer();
>         while (urls.hasMoreElements()) {
>             URL url = urls.nextElement();
>             VirtualFile file = VFS.getRoot(url);
>             buffer.append(file.getPathName() + "\n");
>         }
>         new PrintWriter(resp.getOutputStream()).println(buffer.toString());
>     }
> }
> Trying to access the servlet results in an error when one URL is converted to a VirtualFile by VFS.getRoot(), and here is the resulting exception. The URL that triggers the error differs if the test is repeated.
> 00:45:44,380 ERROR [[resource-servlet]] Servlet.service() for servlet resource-servlet threw exception
> java.io.IOException: Child not found opt/jboss/jboss-5.0.1.GA/server/default/deployers/jbossws.deployer/policy.jar/ for MemoryContextHandler at 555514482[path= context=vfsmemory://3j011-j4xs2m-fuc3y7a8-1-fuc3yl41-9 real=vfsmemory://3j011-j4xs2m-fuc3y7a8-1-fuc3yl41-9], available children: []
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.findHandler(DefaultVFSRegistry.java:109)
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:88)
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:121)
> 	at org.jboss.virtual.VFS.getRoot(VFS.java:276)
> 	at BasicServlet.doGet(BasicServlet.java:22)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 08:50:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 24 Jun 2009 08:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1437) Browsers
 should iterate on queue
In-Reply-To: <33355941.1225819521109.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12428626.1245847856501.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1437.
------------------------------------

    Resolution: Done


fixed in the trunk

> Browsers should iterate on queue
> --------------------------------
>
>                 Key: JBMESSAGING-1437
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1437
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>         Attachments: patch-JBMESSAGING-1437.txt
>
>
> Currently the server browser implementation is taking a snapshot of the queue and browsing that. Instead we should implement an iterator on the queue which allows refs to be added or removed from the ends without affecting it.
> This is also necessary to allow failover for browsers which is very hard to implement with the current snapshot approach

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 08:54:56 2009
From: jira-events at lists.jboss.org (Jesus Menendez (JIRA))
Date: Wed, 24 Jun 2009 08:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7053)
 org.jboss.security.jacc.SubjectPolicyContexthandler looking two levels up
 into RunAsIdentity stack
Message-ID: <20739813.1245848096552.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.security.jacc.SubjectPolicyContexthandler looking two levels up into RunAsIdentity stack
--------------------------------------------------------------------------------------------------

                 Key: JBAS-7053
                 URL: https://jira.jboss.org/jira/browse/JBAS-7053
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.2.3.GA, JBossAS-4.2.2.GA
            Reporter: Jesus Menendez
            Assignee: Anil Saldhana



Connfiguration of EJB is
ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee">
  <enterprise-beans>
    <session> 
         <ejb-name>editors</ejb-name>
         <mapped-name>ejb/assethouse/goya/process/agents/editors</mapped-name>
         <business-local>com.assethouse.goya.process.agent.Agent</business-local>
         <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
         <session-type>Stateless</session-type>
         <timeout-method>
              <method-name>startTask</method-name>
         </timeout-method>
         <security-identity>
            <run-as>
                <description>Group for editors Partition</description>
                <role-name>editors</role-name>
            </run-as>
         </security-identity>
      </session>
     <session>
         <ejb-name>publishers</ejb-name>
        <mapped-name>ejb/assethouse/goya/process/agents/publishers</mapped-name>
        <business-local>com.assethouse.goya.process.agent.Agent</business-local>
        <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
        <session-type>Stateless</session-type>
        <timeout-method>
           <method-name>startTask</method-name>
           </timeout-method>
        <security-identity>
           <run-as>
               <description>Group for publishers Partition</description>
               <role-name>publishers</role-name>
           </run-as>
        </security-identity>
     </session>
     
</enterprise-beans>
<assembly-descriptor>
   <security-role>
       <role-name>editors</role-name>
    </security-role>
    <security-role>
        <role-name>publisher</role-name>
     </security-role>
  </assembly-descriptor>
</ejb-jar>



jboss.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC
    "-//JBoss//DTD JBOSS 4_2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">

<jboss>

    <security-domain>java:/jaas/process</security-domain>
    
    <enterprise-beans>
        <session>
            <ejb-name>editors</ejb-name>
            <security-identity>
                <run-as-principal>editor</run-as-principal>
            </security-identity>
        </session>

        <session>
            <ejb-name>publishers</ejb-name>
            <security-identity>
                <run-as-principal>publisher</run-as-principal>
            </security-identity>
        </session>

    </enterprise-beans>

    <assembly-descriptor>
        <security-role>
            <role-name>publishers</role-name>
            <principal-name>publisher</principal-name>
        </security-role>
        <security-role>
            <role-name>editors</role-name>
            <principal-name>editor</principal-name>
        </security-role>
    </assembly-descriptor>

</jboss>


Also configured the login-module with a new security domain with an UserRoleLoginModule plugin

roles.properties
   publisher=publishers
   editor=editors

user.properties
     publisher=password
     editor=password


When I use PolicyContext.getContext("") within and AgentBean method it should return the RunAsIdentity of that method as declared in the run-as . it returns anonymous wihch is the current authenticated user.. not the one specified in run-as

When I looked at the source code  in org.jboss.security.jacc.SubjectPolicyContexthandler
I saw this method call in  lines 55 and 73
RunAsIdentity callerRunAsIdentity = (RunAsIdentity)
               SecurityAssociation.peekRunAsIdentity(1);

What I did is to change the parameter from a value of 1 to a value of 0 so it peeks the top element in the stack
I patched Jboss with this modification and the PolicyContext.getContext("") started returning the right values (editors and publishers)

So, do you think this is a bug in org.jboss.security.jacc.SubjectPolicyContexthandler
Why SecurityAssociation.peekRunAsIdentity is it being called with a parameter value of 1. That is looking two levels down in the stack isn't it? 



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 08:58:56 2009
From: jira-events at lists.jboss.org (Jesus Menendez (JIRA))
Date: Wed, 24 Jun 2009 08:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7053)
 org.jboss.security.jacc.SubjectPolicyContexthandler looking two levels up
 into RunAsIdentity stack
In-Reply-To: <20739813.1245848096552.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22640578.1245848336778.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesus Menendez updated JBAS-7053:
---------------------------------

    Description: 
I configured two EJBs to make use of the run-as security identity tag
The EJBS implement a class called AgentBean

When I use PolicyContext.getContext("javax.security.auth.Subject.container") within and AgentBean method it should return the RunAsIdentity of that method as declared in the run-as tag . it returns anonymous wihch is the current authenticated user.. not the one specified in run-as


When I looked at the source code  in org.jboss.security.jacc.SubjectPolicyContexthandler
I saw this method call in  lines 55 and 73
RunAsIdentity callerRunAsIdentity = (RunAsIdentity)
               SecurityAssociation.peekRunAsIdentity(1);

What I did is to change the parameter from a value of 1 to a value of 0 so it peeks the top element in the stack
I patched Jboss with this modification and the PolicyContext.getContext("javax.security.auth.Subject.container") started returning the right values (editors and publishers)

So, do you think this is a bug in org.jboss.security.jacc.SubjectPolicyContexthandler
Why SecurityAssociation.peekRunAsIdentity is it being called with a parameter value of 1. That is looking two levels down in the stack isn't it? 




Connfiguration of EJB is
ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee">
  <enterprise-beans>
    <session> 
         <ejb-name>editors</ejb-name>
         <mapped-name>ejb/assethouse/goya/process/agents/editors</mapped-name>
         <business-local>com.assethouse.goya.process.agent.Agent</business-local>
         <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
         <session-type>Stateless</session-type>
         <timeout-method>
              <method-name>startTask</method-name>
         </timeout-method>
         <security-identity>
            <run-as>
                <description>Group for editors Partition</description>
                <role-name>editors</role-name>
            </run-as>
         </security-identity>
      </session>
     <session>
         <ejb-name>publishers</ejb-name>
        <mapped-name>ejb/assethouse/goya/process/agents/publishers</mapped-name>
        <business-local>com.assethouse.goya.process.agent.Agent</business-local>
        <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
        <session-type>Stateless</session-type>
        <timeout-method>
           <method-name>startTask</method-name>
           </timeout-method>
        <security-identity>
           <run-as>
               <description>Group for publishers Partition</description>
               <role-name>publishers</role-name>
           </run-as>
        </security-identity>
     </session>
     
</enterprise-beans>
<assembly-descriptor>
   <security-role>
       <role-name>editors</role-name>
    </security-role>
    <security-role>
        <role-name>publisher</role-name>
     </security-role>
  </assembly-descriptor>
</ejb-jar>



jboss.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC
    "-//JBoss//DTD JBOSS 4_2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">

<jboss>

    <security-domain>java:/jaas/process</security-domain>
    
    <enterprise-beans>
        <session>
            <ejb-name>editors</ejb-name>
            <security-identity>
                <run-as-principal>editor</run-as-principal>
            </security-identity>
        </session>

        <session>
            <ejb-name>publishers</ejb-name>
            <security-identity>
                <run-as-principal>publisher</run-as-principal>
            </security-identity>
        </session>

    </enterprise-beans>

    <assembly-descriptor>
        <security-role>
            <role-name>publishers</role-name>
            <principal-name>publisher</principal-name>
        </security-role>
        <security-role>
            <role-name>editors</role-name>
            <principal-name>editor</principal-name>
        </security-role>
    </assembly-descriptor>

</jboss>


Also configured the login-module with a new security domain with an UserRoleLoginModule plugin

roles.properties
   publisher=publishers
   editor=editors

user.properties
     publisher=password
     editor=password




  was:

Connfiguration of EJB is
ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee">
  <enterprise-beans>
    <session> 
         <ejb-name>editors</ejb-name>
         <mapped-name>ejb/assethouse/goya/process/agents/editors</mapped-name>
         <business-local>com.assethouse.goya.process.agent.Agent</business-local>
         <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
         <session-type>Stateless</session-type>
         <timeout-method>
              <method-name>startTask</method-name>
         </timeout-method>
         <security-identity>
            <run-as>
                <description>Group for editors Partition</description>
                <role-name>editors</role-name>
            </run-as>
         </security-identity>
      </session>
     <session>
         <ejb-name>publishers</ejb-name>
        <mapped-name>ejb/assethouse/goya/process/agents/publishers</mapped-name>
        <business-local>com.assethouse.goya.process.agent.Agent</business-local>
        <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
        <session-type>Stateless</session-type>
        <timeout-method>
           <method-name>startTask</method-name>
           </timeout-method>
        <security-identity>
           <run-as>
               <description>Group for publishers Partition</description>
               <role-name>publishers</role-name>
           </run-as>
        </security-identity>
     </session>
     
</enterprise-beans>
<assembly-descriptor>
   <security-role>
       <role-name>editors</role-name>
    </security-role>
    <security-role>
        <role-name>publisher</role-name>
     </security-role>
  </assembly-descriptor>
</ejb-jar>



jboss.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC
    "-//JBoss//DTD JBOSS 4_2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">

<jboss>

    <security-domain>java:/jaas/process</security-domain>
    
    <enterprise-beans>
        <session>
            <ejb-name>editors</ejb-name>
            <security-identity>
                <run-as-principal>editor</run-as-principal>
            </security-identity>
        </session>

        <session>
            <ejb-name>publishers</ejb-name>
            <security-identity>
                <run-as-principal>publisher</run-as-principal>
            </security-identity>
        </session>

    </enterprise-beans>

    <assembly-descriptor>
        <security-role>
            <role-name>publishers</role-name>
            <principal-name>publisher</principal-name>
        </security-role>
        <security-role>
            <role-name>editors</role-name>
            <principal-name>editor</principal-name>
        </security-role>
    </assembly-descriptor>

</jboss>


Also configured the login-module with a new security domain with an UserRoleLoginModule plugin

roles.properties
   publisher=publishers
   editor=editors

user.properties
     publisher=password
     editor=password


When I use PolicyContext.getContext("") within and AgentBean method it should return the RunAsIdentity of that method as declared in the run-as . it returns anonymous wihch is the current authenticated user.. not the one specified in run-as

When I looked at the source code  in org.jboss.security.jacc.SubjectPolicyContexthandler
I saw this method call in  lines 55 and 73
RunAsIdentity callerRunAsIdentity = (RunAsIdentity)
               SecurityAssociation.peekRunAsIdentity(1);

What I did is to change the parameter from a value of 1 to a value of 0 so it peeks the top element in the stack
I patched Jboss with this modification and the PolicyContext.getContext("") started returning the right values (editors and publishers)

So, do you think this is a bug in org.jboss.security.jacc.SubjectPolicyContexthandler
Why SecurityAssociation.peekRunAsIdentity is it being called with a parameter value of 1. That is looking two levels down in the stack isn't it? 





> org.jboss.security.jacc.SubjectPolicyContexthandler looking two levels up into RunAsIdentity stack
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7053
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7053
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.3.GA
>            Reporter: Jesus Menendez
>            Assignee: Anil Saldhana
>
> I configured two EJBs to make use of the run-as security identity tag
> The EJBS implement a class called AgentBean
> When I use PolicyContext.getContext("javax.security.auth.Subject.container") within and AgentBean method it should return the RunAsIdentity of that method as declared in the run-as tag . it returns anonymous wihch is the current authenticated user.. not the one specified in run-as
> When I looked at the source code  in org.jboss.security.jacc.SubjectPolicyContexthandler
> I saw this method call in  lines 55 and 73
> RunAsIdentity callerRunAsIdentity = (RunAsIdentity)
>                SecurityAssociation.peekRunAsIdentity(1);
> What I did is to change the parameter from a value of 1 to a value of 0 so it peeks the top element in the stack
> I patched Jboss with this modification and the PolicyContext.getContext("javax.security.auth.Subject.container") started returning the right values (editors and publishers)
> So, do you think this is a bug in org.jboss.security.jacc.SubjectPolicyContexthandler
> Why SecurityAssociation.peekRunAsIdentity is it being called with a parameter value of 1. That is looking two levels down in the stack isn't it? 
> Connfiguration of EJB is
> ejb-jar.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <ejb-jar version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee">
>   <enterprise-beans>
>     <session> 
>          <ejb-name>editors</ejb-name>
>          <mapped-name>ejb/assethouse/goya/process/agents/editors</mapped-name>
>          <business-local>com.assethouse.goya.process.agent.Agent</business-local>
>          <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
>          <session-type>Stateless</session-type>
>          <timeout-method>
>               <method-name>startTask</method-name>
>          </timeout-method>
>          <security-identity>
>             <run-as>
>                 <description>Group for editors Partition</description>
>                 <role-name>editors</role-name>
>             </run-as>
>          </security-identity>
>       </session>
>      <session>
>          <ejb-name>publishers</ejb-name>
>         <mapped-name>ejb/assethouse/goya/process/agents/publishers</mapped-name>
>         <business-local>com.assethouse.goya.process.agent.Agent</business-local>
>         <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
>         <session-type>Stateless</session-type>
>         <timeout-method>
>            <method-name>startTask</method-name>
>            </timeout-method>
>         <security-identity>
>            <run-as>
>                <description>Group for publishers Partition</description>
>                <role-name>publishers</role-name>
>            </run-as>
>         </security-identity>
>      </session>
>      
> </enterprise-beans>
> <assembly-descriptor>
>    <security-role>
>        <role-name>editors</role-name>
>     </security-role>
>     <security-role>
>         <role-name>publisher</role-name>
>      </security-role>
>   </assembly-descriptor>
> </ejb-jar>
> jboss.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE jboss PUBLIC
>     "-//JBoss//DTD JBOSS 4_2//EN"
>     "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">
> <jboss>
>     <security-domain>java:/jaas/process</security-domain>
>     
>     <enterprise-beans>
>         <session>
>             <ejb-name>editors</ejb-name>
>             <security-identity>
>                 <run-as-principal>editor</run-as-principal>
>             </security-identity>
>         </session>
>         <session>
>             <ejb-name>publishers</ejb-name>
>             <security-identity>
>                 <run-as-principal>publisher</run-as-principal>
>             </security-identity>
>         </session>
>     </enterprise-beans>
>     <assembly-descriptor>
>         <security-role>
>             <role-name>publishers</role-name>
>             <principal-name>publisher</principal-name>
>         </security-role>
>         <security-role>
>             <role-name>editors</role-name>
>             <principal-name>editor</principal-name>
>         </security-role>
>     </assembly-descriptor>
> </jboss>
> Also configured the login-module with a new security domain with an UserRoleLoginModule plugin
> roles.properties
>    publisher=publishers
>    editor=editors
> user.properties
>      publisher=password
>      editor=password

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 09:01:07 2009
From: jira-events at lists.jboss.org (Jesus Menendez (JIRA))
Date: Wed, 24 Jun 2009 09:01:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7053)
 org.jboss.security.jacc.SubjectPolicyContexthandler looking two levels up
 into RunAsIdentity stack
In-Reply-To: <20739813.1245848096552.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20607412.1245848467276.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesus Menendez updated JBAS-7053:
---------------------------------

    Description: 
I configured two EJBs to make use of the run-as security identity tag
The EJBS implement a class called AgentBean

When I use PolicyContext.getContext("javax.security.auth.Subject.container") within and AgentBean method it should return the RunAsIdentity of that method as declared in the run-as tag . it returns anonymous wihch is the current authenticated user.. not the one specified in run-as


When I looked at the source code  in org.jboss.security.jacc.SubjectPolicyContexthandler
I saw this method call in  lines 55 and 73
RunAsIdentity callerRunAsIdentity = (RunAsIdentity)
               SecurityAssociation.peekRunAsIdentity(1);

What I did is to change the parameter from a value of 1 to a value of 0 so it peeks the top element in the stack
I patched Jboss with this modification and the PolicyContext.getContext("javax.security.auth.Subject.container") started returning the right values

So, do you think this is a bug in org.jboss.security.jacc.SubjectPolicyContexthandler
Why SecurityAssociation.peekRunAsIdentity is it being called with a parameter value of 1. That is looking two levels down in the stack isn't it? 




Connfiguration of EJB is
ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee">
  <enterprise-beans>
    <session> 
         <ejb-name>editors</ejb-name>
         <mapped-name>ejb/assethouse/goya/process/agents/editors</mapped-name>
         <business-local>com.assethouse.goya.process.agent.Agent</business-local>
         <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
         <session-type>Stateless</session-type>
         <timeout-method>
              <method-name>startTask</method-name>
         </timeout-method>
         <security-identity>
            <run-as>
                <description>Group for editors Partition</description>
                <role-name>editors</role-name>
            </run-as>
         </security-identity>
      </session>
     <session>
         <ejb-name>publishers</ejb-name>
        <mapped-name>ejb/assethouse/goya/process/agents/publishers</mapped-name>
        <business-local>com.assethouse.goya.process.agent.Agent</business-local>
        <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
        <session-type>Stateless</session-type>
        <timeout-method>
           <method-name>startTask</method-name>
           </timeout-method>
        <security-identity>
           <run-as>
               <description>Group for publishers Partition</description>
               <role-name>publishers</role-name>
           </run-as>
        </security-identity>
     </session>
     
</enterprise-beans>
<assembly-descriptor>
   <security-role>
       <role-name>editors</role-name>
    </security-role>
    <security-role>
        <role-name>publisher</role-name>
     </security-role>
  </assembly-descriptor>
</ejb-jar>



jboss.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC
    "-//JBoss//DTD JBOSS 4_2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">

<jboss>

    <security-domain>java:/jaas/process</security-domain>
    
    <enterprise-beans>
        <session>
            <ejb-name>editors</ejb-name>
            <security-identity>
                <run-as-principal>editor</run-as-principal>
            </security-identity>
        </session>

        <session>
            <ejb-name>publishers</ejb-name>
            <security-identity>
                <run-as-principal>publisher</run-as-principal>
            </security-identity>
        </session>

    </enterprise-beans>

    <assembly-descriptor>
        <security-role>
            <role-name>publishers</role-name>
            <principal-name>publisher</principal-name>
        </security-role>
        <security-role>
            <role-name>editors</role-name>
            <principal-name>editor</principal-name>
        </security-role>
    </assembly-descriptor>

</jboss>


Also configured the login-module with a new security domain with an UserRoleLoginModule plugin

roles.properties
   publisher=publishers
   editor=editors

user.properties
     publisher=password
     editor=password




  was:
I configured two EJBs to make use of the run-as security identity tag
The EJBS implement a class called AgentBean

When I use PolicyContext.getContext("javax.security.auth.Subject.container") within and AgentBean method it should return the RunAsIdentity of that method as declared in the run-as tag . it returns anonymous wihch is the current authenticated user.. not the one specified in run-as


When I looked at the source code  in org.jboss.security.jacc.SubjectPolicyContexthandler
I saw this method call in  lines 55 and 73
RunAsIdentity callerRunAsIdentity = (RunAsIdentity)
               SecurityAssociation.peekRunAsIdentity(1);

What I did is to change the parameter from a value of 1 to a value of 0 so it peeks the top element in the stack
I patched Jboss with this modification and the PolicyContext.getContext("javax.security.auth.Subject.container") started returning the right values (editors and publishers)

So, do you think this is a bug in org.jboss.security.jacc.SubjectPolicyContexthandler
Why SecurityAssociation.peekRunAsIdentity is it being called with a parameter value of 1. That is looking two levels down in the stack isn't it? 




Connfiguration of EJB is
ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee">
  <enterprise-beans>
    <session> 
         <ejb-name>editors</ejb-name>
         <mapped-name>ejb/assethouse/goya/process/agents/editors</mapped-name>
         <business-local>com.assethouse.goya.process.agent.Agent</business-local>
         <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
         <session-type>Stateless</session-type>
         <timeout-method>
              <method-name>startTask</method-name>
         </timeout-method>
         <security-identity>
            <run-as>
                <description>Group for editors Partition</description>
                <role-name>editors</role-name>
            </run-as>
         </security-identity>
      </session>
     <session>
         <ejb-name>publishers</ejb-name>
        <mapped-name>ejb/assethouse/goya/process/agents/publishers</mapped-name>
        <business-local>com.assethouse.goya.process.agent.Agent</business-local>
        <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
        <session-type>Stateless</session-type>
        <timeout-method>
           <method-name>startTask</method-name>
           </timeout-method>
        <security-identity>
           <run-as>
               <description>Group for publishers Partition</description>
               <role-name>publishers</role-name>
           </run-as>
        </security-identity>
     </session>
     
</enterprise-beans>
<assembly-descriptor>
   <security-role>
       <role-name>editors</role-name>
    </security-role>
    <security-role>
        <role-name>publisher</role-name>
     </security-role>
  </assembly-descriptor>
</ejb-jar>



jboss.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC
    "-//JBoss//DTD JBOSS 4_2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">

<jboss>

    <security-domain>java:/jaas/process</security-domain>
    
    <enterprise-beans>
        <session>
            <ejb-name>editors</ejb-name>
            <security-identity>
                <run-as-principal>editor</run-as-principal>
            </security-identity>
        </session>

        <session>
            <ejb-name>publishers</ejb-name>
            <security-identity>
                <run-as-principal>publisher</run-as-principal>
            </security-identity>
        </session>

    </enterprise-beans>

    <assembly-descriptor>
        <security-role>
            <role-name>publishers</role-name>
            <principal-name>publisher</principal-name>
        </security-role>
        <security-role>
            <role-name>editors</role-name>
            <principal-name>editor</principal-name>
        </security-role>
    </assembly-descriptor>

</jboss>


Also configured the login-module with a new security domain with an UserRoleLoginModule plugin

roles.properties
   publisher=publishers
   editor=editors

user.properties
     publisher=password
     editor=password






> org.jboss.security.jacc.SubjectPolicyContexthandler looking two levels up into RunAsIdentity stack
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7053
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7053
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.3.GA
>            Reporter: Jesus Menendez
>            Assignee: Anil Saldhana
>
> I configured two EJBs to make use of the run-as security identity tag
> The EJBS implement a class called AgentBean
> When I use PolicyContext.getContext("javax.security.auth.Subject.container") within and AgentBean method it should return the RunAsIdentity of that method as declared in the run-as tag . it returns anonymous wihch is the current authenticated user.. not the one specified in run-as
> When I looked at the source code  in org.jboss.security.jacc.SubjectPolicyContexthandler
> I saw this method call in  lines 55 and 73
> RunAsIdentity callerRunAsIdentity = (RunAsIdentity)
>                SecurityAssociation.peekRunAsIdentity(1);
> What I did is to change the parameter from a value of 1 to a value of 0 so it peeks the top element in the stack
> I patched Jboss with this modification and the PolicyContext.getContext("javax.security.auth.Subject.container") started returning the right values
> So, do you think this is a bug in org.jboss.security.jacc.SubjectPolicyContexthandler
> Why SecurityAssociation.peekRunAsIdentity is it being called with a parameter value of 1. That is looking two levels down in the stack isn't it? 
> Connfiguration of EJB is
> ejb-jar.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <ejb-jar version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee">
>   <enterprise-beans>
>     <session> 
>          <ejb-name>editors</ejb-name>
>          <mapped-name>ejb/assethouse/goya/process/agents/editors</mapped-name>
>          <business-local>com.assethouse.goya.process.agent.Agent</business-local>
>          <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
>          <session-type>Stateless</session-type>
>          <timeout-method>
>               <method-name>startTask</method-name>
>          </timeout-method>
>          <security-identity>
>             <run-as>
>                 <description>Group for editors Partition</description>
>                 <role-name>editors</role-name>
>             </run-as>
>          </security-identity>
>       </session>
>      <session>
>          <ejb-name>publishers</ejb-name>
>         <mapped-name>ejb/assethouse/goya/process/agents/publishers</mapped-name>
>         <business-local>com.assethouse.goya.process.agent.Agent</business-local>
>         <ejb-class>com.assethouse.goya.process.agent.AgentBean</ejb-class>
>         <session-type>Stateless</session-type>
>         <timeout-method>
>            <method-name>startTask</method-name>
>            </timeout-method>
>         <security-identity>
>            <run-as>
>                <description>Group for publishers Partition</description>
>                <role-name>publishers</role-name>
>            </run-as>
>         </security-identity>
>      </session>
>      
> </enterprise-beans>
> <assembly-descriptor>
>    <security-role>
>        <role-name>editors</role-name>
>     </security-role>
>     <security-role>
>         <role-name>publisher</role-name>
>      </security-role>
>   </assembly-descriptor>
> </ejb-jar>
> jboss.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE jboss PUBLIC
>     "-//JBoss//DTD JBOSS 4_2//EN"
>     "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">
> <jboss>
>     <security-domain>java:/jaas/process</security-domain>
>     
>     <enterprise-beans>
>         <session>
>             <ejb-name>editors</ejb-name>
>             <security-identity>
>                 <run-as-principal>editor</run-as-principal>
>             </security-identity>
>         </session>
>         <session>
>             <ejb-name>publishers</ejb-name>
>             <security-identity>
>                 <run-as-principal>publisher</run-as-principal>
>             </security-identity>
>         </session>
>     </enterprise-beans>
>     <assembly-descriptor>
>         <security-role>
>             <role-name>publishers</role-name>
>             <principal-name>publisher</principal-name>
>         </security-role>
>         <security-role>
>             <role-name>editors</role-name>
>             <principal-name>editor</principal-name>
>         </security-role>
>     </assembly-descriptor>
> </jboss>
> Also configured the login-module with a new security domain with an UserRoleLoginModule plugin
> roles.properties
>    publisher=publishers
>    editor=editors
> user.properties
>      publisher=password
>      editor=password

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 09:19:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Wed, 24 Jun 2009 09:19:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
Message-ID: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>

Wrong deployers ordering when multiple inputs specified on many deployers
-------------------------------------------------------------------------

                 Key: JBDEPLOY-201
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
             Project: JBoss Deployers
          Issue Type: Bug
          Components: deployer
    Affects Versions: JBDEPLOY-2.0.8.GA
            Reporter: Richard Opalka
             Fix For:  JBDEPLOY-2.2.x




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 09:23:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Wed, 24 Jun 2009 09:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23015866.1245849836463.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473604#action_12473604 ] 

Richard Opalka commented on JBDEPLOY-201:
-----------------------------------------

[/home/opalka][/opt/svn/jbossas/projects/jboss-deployers/trunk/deployers-impl]>svn ci -m "[JBDEPLOY-201] providing test case"
Sending        deployers-impl/src/test/java/org/jboss/test/deployers/deployer/test/DeployerFlowUnitTestCase.java
Transmitting file data .
Committed revision 90554.

> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 09:41:56 2009
From: jira-events at lists.jboss.org (Marius Bogoevici (JIRA))
Date: Wed, 24 Jun 2009 09:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBVFS-109) Trying to access
 all classpath
 resources from a web application fails due to VFS errors
In-Reply-To: <14030842.1241499346657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23250123.1245850916631.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBVFS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473608#action_12473608 ] 

Marius Bogoevici commented on JBVFS-109:
----------------------------------------

Naresh, 

for a solution to the classpath scanning problem, please refer to http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239767#4239767

This issue is strictly addressing the incorrect internal VFS behaviour and has nothing to do with Spring per se.

Marius

> Trying to access all classpath resources from a web application fails due to VFS errors
> ---------------------------------------------------------------------------------------
>
>                 Key: JBVFS-109
>                 URL: https://jira.jboss.org/jira/browse/JBVFS-109
>             Project: JBoss VFS
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>            Reporter: Marius Bogoevici
>            Assignee: Ales Justin
>             Fix For: 2.1.2.GA
>
>         Attachments: spring-jboss-jaxws.tar.gz
>
>
> The error has been triggered by using classpath scanning in Spring, but can be reproduced independently.
> The code in the servlet listed below does virtually the same thing as the VFSResourcePatternResolver:
> public class BasicServlet extends HttpServlet{
>     @Override
>     protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
>         ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
>         Enumeration<URL> urls = classLoader.getResources("");
>         StringBuffer buffer = new StringBuffer();
>         while (urls.hasMoreElements()) {
>             URL url = urls.nextElement();
>             VirtualFile file = VFS.getRoot(url);
>             buffer.append(file.getPathName() + "\n");
>         }
>         new PrintWriter(resp.getOutputStream()).println(buffer.toString());
>     }
> }
> Trying to access the servlet results in an error when one URL is converted to a VirtualFile by VFS.getRoot(), and here is the resulting exception. The URL that triggers the error differs if the test is repeated.
> 00:45:44,380 ERROR [[resource-servlet]] Servlet.service() for servlet resource-servlet threw exception
> java.io.IOException: Child not found opt/jboss/jboss-5.0.1.GA/server/default/deployers/jbossws.deployer/policy.jar/ for MemoryContextHandler at 555514482[path= context=vfsmemory://3j011-j4xs2m-fuc3y7a8-1-fuc3yl41-9 real=vfsmemory://3j011-j4xs2m-fuc3y7a8-1-fuc3yl41-9], available children: []
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.findHandler(DefaultVFSRegistry.java:109)
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:88)
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:121)
> 	at org.jboss.virtual.VFS.getRoot(VFS.java:276)
> 	at BasicServlet.doGet(BasicServlet.java:22)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 10:04:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 24 Jun 2009 10:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6534180.1245852296843.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473612#action_12473612 ] 

Alexey Loubyansky commented on JBXB-206:
----------------------------------------

If I start current AS trunk, looking into the logs, I don't see any call to org.jboss.xb.binding.Util#loadSchema(java.io.InputStream, String, org.jboss.xb.binding.sunday.unmarshalling.SchemaBindingResolver).

> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>         Attachments: jboss-profiler.properties, jbossxb.zip, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 10:45:56 2009
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Wed, 24 Jun 2009 10:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1000) COMPRESS corrupts
	some messages
Message-ID: <7560851.1245854756549.JavaMail.jira@cloud.prod.atl2.jboss.com>

COMPRESS corrupts some messages
-------------------------------

                 Key: JGRP-1000
                 URL: https://jira.jboss.org/jira/browse/JGRP-1000
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.4.5
            Reporter: Dennis Reed
            Assignee: Dennis Reed


COMPRESS.down() stores the compressed message in a temporary buffer the same size as the original message.

If the compressed size of a message is larger than the original, then part of the message is lost, with no errors reported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 10:48:58 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 24 Jun 2009 10:48:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7050) Unable to create
 any kind of datasource or connection factory
Message-ID: <32789699.1245854938555.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473623#action_12473623 ] 

Ian Springer commented on JBAS-7050:
------------------------------------

I've updated the client code at https://svn.jboss.org/repos/jopr/trunk/etc/jbas5-ejb-client/ to reproduce this.


> Unable to create any kind of datasource or connection factory
> -------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 10:50:57 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 24 Jun 2009 10:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7050) Unable to create any
 kind of datasource or connection factory
Message-ID: <7067917.1245855057590.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7050:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> Unable to create any kind of datasource or connection factory
> -------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 10:50:57 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 24 Jun 2009 10:50:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19758451.1245855057038.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473626#action_12473626 ] 

Jesper Pedersen commented on JBXB-206:
--------------------------------------

This is not AS - I'm using the XB API directly:

MutableSchemaResolver msr = new MultiClassSchemaResolver();


> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>         Attachments: jboss-profiler.properties, jbossxb.zip, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 11:04:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 24 Jun 2009 11:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7052) when invoked from
 remote client, 
 call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15335337.1245855896741.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7052:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         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.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 11:06:58 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 24 Jun 2009 11:06:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17125844.1245856018335.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7051:
-------------------------------

    Labels: EmbJopr1_3 ProfileService  (was: )


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         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.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         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.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.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         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.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 11:35:57 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 24 Jun 2009 11:35:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-740) More workarounds for
 bug in IBM's Class.getDeclaringClass() implementation
In-Reply-To: <10151921.1245758756509.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16931186.1245857757225.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAOP-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed JBAOP-740.
----------------------------

    Resolution: Done
      Assignee: Kabir Khan


> More workarounds for bug in IBM's Class.getDeclaringClass() implementation
> --------------------------------------------------------------------------
>
>                 Key: JBAOP-740
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-740
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.2.GA
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 2.1.3.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 11:57:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 24 Jun 2009 11:57:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <736877.1245859077129.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7049:
---------------------------------


Anil, this also fails on branch JBPAPP_5_0.

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 12:11:56 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Wed, 24 Jun 2009 12:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-123) Use QA databases for
 sql scripts creation
In-Reply-To: <4718364.1243587716425.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11161236.1245859916701.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Yu updated JBID-123:
-------------------------

    Fix Version/s: idm-1.0.0.Beta1
                       (was: idm-1.0.0.CR1)


> Use QA databases for sql scripts creation
> -----------------------------------------
>
>                 Key: JBID-123
>                 URL: https://jira.jboss.org/jira/browse/JBID-123
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Boleslaw Dawidowicz
>            Assignee: Jeff Yu
>             Fix For: idm-1.0.0.Beta1
>
>
> Distro module should use QA databases to generate schema sql scripts instead of local urls. This will let to generate whole range of sql scripts for all currently tested DBs during release process.
> QA database setup is specified in those files:
> http://anonsvn.jboss.org/repos/jbossidentity/idm/tags/1.0.0.Alpha7/idm-testsuite/src/test/resources/datasources/datasources.xml
> http://anonsvn.jboss.org/repos/jbossidentity/idm/tags/1.0.0.Alpha7/idm-testsuite/src/test/resources/datasources/hibernates.xml

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 12:11:57 2009
From: jira-events at lists.jboss.org (Jeff Yu (JIRA))
Date: Wed, 24 Jun 2009 12:11:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-99) Unique attributes
In-Reply-To: <3795253.1242040366371.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28527240.1245859917145.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Yu updated JBID-99:
------------------------

    Fix Version/s: idm-1.0.0.Beta1
                       (was: idm-1.0.0.Beta2)


> Unique attributes
> -----------------
>
>                 Key: JBID-99
>                 URL: https://jira.jboss.org/jira/browse/JBID-99
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: IDM
>            Reporter: Boleslaw Dawidowicz
>            Assignee: Boleslaw Dawidowicz
>             Fix For: idm-1.0.0.Beta1
>
>
> Add possibility to mark attribute as unique. This means that given the value is unique in scope of IdentityObjectType (for Users or within given GroupType). There should be an API to query single User or Group based on such attribute value. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 11:31:08 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 24 Jun 2009 11:31:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6877) EJB3 Entity Cache
	Metrics
In-Reply-To: <13995931.1241642506748.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3842157.1245857468160.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned JBAS-6877:
--------------------------------------

    Assignee: Filip Drabek  (was: Brian Stansberry)


Assigning this to Filip Drabek, as he is handling JOPR-221, which is where the real work is actually happening. Feel free to assign back to me if there is something I need to do.

> EJB3 Entity Cache Metrics
> -------------------------
>
>                 Key: JBAS-6877
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6877
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>            Reporter: Andrew Lee Rubinger
>            Assignee: Filip Drabek
>             Fix For: Backlog
>
>
> These statistics must be reflected in the admin-console/Jopr.
> Split from JBAS-6624:
> EJB3 Entity Tree Cache (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache-->
> <metric property="NumberOfLocksHeld" displayType="summary"/>
>          <metric property="NumberOfNodes" displayType="summary"/>
> EJB3 Entity Tree Cache Interceptor (in addition to availability)
> <!--jboss.cache:service=EJB3EntityTreeCache,treecache-interceptor=CacheMgmtInterceptor-->
>             <metric property="HitMissRatio" displayType="summary" units="percentage"
>                     description="Returns the hit/miss ratio for the cache. This ratio is defined as hits/(hits + misses)."/>
>             <metric property="ReadWriteRatio" displayType="summary" units="percentage"
>                     description="Returns the read/write ratio for the cache. This ratio is defined as (hits + misses)/stores."/>
>             <metric property="Hits" displayType="summary"/>
>             <metric property="Misses" displayType="summary"/>
>             <metric property="Evictions" displayType="summary"/>
>             <metric property="NumberOfLocksHeld"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="AverageWriteTime" units="milliseconds"/>
>             <metric property="TimeSinceReset" units="seconds"/>
>             <metric property="AverageReadTime" units="milliseconds"/>
>             <metric property="NumberOfNodes"/>
>             <metric property="Stores"/>
>             <metric property="NumberOfAttributes"/>
>             <metric property="ElapsedTime" units="milliseconds"/> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 13:04:10 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 24 Jun 2009 13:04:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-5615) Synchronization
 mutex for clustered environments
In-Reply-To: <31351334.1213134137427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11282597.1245863050753.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated JBAS-5615:
-------------------------------

    Attachment: potentialPatch.txt


Test patch, this may not be the final change.

> Synchronization mutex for clustered environments
> ------------------------------------------------
>
>                 Key: JBAS-5615
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5615
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: Nick Belaevski
>            Assignee: Scott Marlow
>            Priority: Minor
>         Attachments: potentialPatch.txt
>
>
> Quote from http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136590 : "they'll need to be thread safe or have access to them synchronized".
> There's no object to synchronize against: SessionBasedClusteredSession doesn synchronization against itself:
>    public void writeExternal(ObjectOutput out) throws IOException
>    {
>       synchronized (this)
>       {
>          ...
>      }   
>    
>    } 
> but application developers see the wrapped one (instance of StandardSessionFacade), so synchronizing against session object does not prevent from concurrency errors

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 14:06:58 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 24 Jun 2009 14:06:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2139) Metaheuristic
 solver: research and development
Message-ID: <9566105.1245866818073.JavaMail.jira@cloud.prod.atl2.jboss.com>

Metaheuristic solver: research and development
----------------------------------------------

                 Key: JBRULES-2139
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2139
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-solver
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet


Bilgin reported better results with metaheuristics on the PAS problem then tabu search, so it will probably be a good idea to implement a metaheuristics solver.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 14:08:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 24 Jun 2009 14:08:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2139) Metaheuristic
 solver: research and development
In-Reply-To: <9566105.1245866818073.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4364749.1245866936431.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473669#action_12473669 ] 

Geoffrey De Smet commented on JBRULES-2139:
-------------------------------------------

How does this relate to phasing? Phasing is the process where you run 10 minutes tabu search, 10 minutes simulated annealing, 10 minutes great deluge, 10 minutes tabu search, ... sequentially after one another on the same problem continue-ing on the results of the previous solver.

> Metaheuristic solver: research and development
> ----------------------------------------------
>
>                 Key: JBRULES-2139
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2139
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>
> Bilgin reported better results with metaheuristics on the PAS problem then tabu search, so it will probably be a good idea to implement a metaheuristics solver.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 14:10:58 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 24 Jun 2009 14:10:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2139) Hyperheuristic
 solver: research and development
In-Reply-To: <9566105.1245866818073.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8179812.1245867058881.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated JBRULES-2139:
--------------------------------------

        Summary: Hyperheuristic solver: research and development  (was: Metaheuristic solver: research and development)
    Description: Bilgin reported better results with a hyperheuristic on the PAS problem then tabu search, so it will probably be a good idea to implement a metaheuristics solver.  (was: Bilgin reported better results with metaheuristics on the PAS problem then tabu search, so it will probably be a good idea to implement a metaheuristics solver.)


> Hyperheuristic solver: research and development
> -----------------------------------------------
>
>                 Key: JBRULES-2139
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2139
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>
> Bilgin reported better results with a hyperheuristic on the PAS problem then tabu search, so it will probably be a good idea to implement a metaheuristics solver.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 15:16:57 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 24 Jun 2009 15:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7013) Seam Booking
 IOException with JSF2 Beta1 on AS5
In-Reply-To: <23174748.1244831337615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2364706.1245871017502.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473688#action_12473688 ] 

Stan Silvert commented on JBAS-7013:
------------------------------------

Opened Mojarra issue for this.  See https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1173

> Seam Booking IOException with JSF2 Beta1 on AS5
> -----------------------------------------------
>
>                 Key: JBAS-7013
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7013
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>
> I drop-in replaced JSF in AS5.1 with JSF 2 Beta 1.  
> With the Seam Booking demo, I bundle the old facelets and have:
>    <context-param>
>       <param-name>javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER</param-name>
>       <param-value>true</param-value>
>     </context-param>
> I get the stack trace below.  Though it doesn't seem to affect the application, I need to figure out why this is happening.
> 13:38:34,463 ERROR [compiler] Error Loading Library: vfszip:/C:/jboss-5.1.0.GA/s
> erver/default/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.tag
> lib.xml
> java.io.IOException: Error parsing [vfszip:/C:/jboss-5.1.0.GA/server/default/dep
> loy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.taglib.xml]:
>         at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.ja
> va:410)
>         at com.sun.facelets.compiler.TagLibraryConfig.loadImplicit(TagLibraryCon
> fig.java:431)
>         at com.sun.facelets.compiler.Compiler.initialize(Compiler.java:87)
>         at com.sun.facelets.compiler.Compiler.compile(Compiler.java:104)
>         at com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFace
> letFactory.java:218)
>         at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFacelet
> Factory.java:149)
>         at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFacelet
> Factory.java:100)
>         at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java
> :517)
>         at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.jav
> a:567)
>         at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWra
> pper.java:108)
>         at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.j
> ava:216)
>         at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePha
> se.java:124)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:103)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:311)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFi
> lter.java:96)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> alve.java:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> alve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(Securit
> yAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValv
> e.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.proce
> ss(SecurityContextEstablishmentValve.java:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invok
> e(SecurityContextEstablishmentValve.java:70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> ava:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> ava:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedC
> onnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> ve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
> a:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
> :829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
> ss(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44
> 7)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: org.xml.sax.SAXException: Error Handling [vfszip:/C:/jboss-5.1.0.GA/s
> erver/default/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.tag
> lib.xml at 42,29]
>         at com.sun.facelets.compiler.TagLibraryConfig$LibraryHandler.error(TagLi
> braryConfig.java:376)
>         at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
>         at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>         at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>         at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>         at org.apache.xerces.impl.dtd.XMLDTDValidator.rootElementSpecified(Unkno
> wn Source)
>         at org.apache.xerces.impl.dtd.XMLDTDValidator.handleStartElement(Unknown
>  Source)
>         at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Sourc
> e)
>         at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElemen
> t(Unknown Source)
>         at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanR
> ootElementHook(Unknown Source)
>         at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
> Dispatcher.dispatch(Unknown Source)
>         at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un
> known Source)
>         at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>         at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>         at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>         at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
>         at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Sour
> ce)
>         at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
>         at javax.xml.parsers.SAXParser.parse(SAXParser.java:198)
>         at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.ja
> va:407)
>         ... 54 more
> Caused by: org.xml.sax.SAXParseException: Document root element "facelet-taglib"
> , must match DOCTYPE root "null".
>         at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Un
> known Source)
>         ... 73 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 15:24:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 24 Jun 2009 15:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7055)
 testValidateSBMContent having problems with hostnames
Message-ID: <3567712.1245871496476.JavaMail.jira@cloud.prod.atl2.jboss.com>

testValidateSBMContent having problems with hostnames 
------------------------------------------------------

                 Key: JBAS-7055
                 URL: https://jira.jboss.org/jira/browse/JBAS-7055
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
         Environment: Solaris 9/10 both x86 and sparc
HPUX both ia64 and risc 
            Reporter: Richard Achmatowicz
            Assignee: Scott M Stark
            Priority: Minor


See the JBPAPP-2139 issue for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 17:17:57 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Wed, 24 Jun 2009 17:17:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-124) Implement WS-T SAML
 Token Profile:: SAMLV2.0 validation
In-Reply-To: <26312958.1243987260389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22673563.1245878277225.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen reopened JBID-124:
---------------------------------



Reopening as the token signature validation needs to be moved to the request handler.

> Implement WS-T SAML Token Profile:: SAMLV2.0 validation
> -------------------------------------------------------
>
>                 Key: JBID-124
>                 URL: https://jira.jboss.org/jira/browse/JBID-124
>             Project: JBoss Identity
>          Issue Type: Sub-task
>          Components: Identity-Federation
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha3
>
>
> The SAML token provider must be able to validate the assertions it generates. This involves validating the digital signature and also the assertion validity period (lifetime).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 17:30:56 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Wed, 24 Jun 2009 17:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-124) Implement WS-T SAML
 Token Profile:: SAMLV2.0 validation
In-Reply-To: <26312958.1243987260389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27933085.1245879056541.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBID-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen closed JBID-124.
-------------------------------

    Resolution: Done


Security token are now signed by the request handler. The digital signature validation code has also been moved to the handler, as it is a common validation procedure that applies to most (if not all) types of tokens. Tests have been updated to reflect the changes.

The WSTrustJAXBFactory now preserves any token elements from JAXB (un)marshalling to prevent changes to signed elements. This means that:
- when marshalling a JAXB content tree, token elements are removed from the JAXB objects before marshalling. After the JAXB objects are marshalled to a document, the original token elements are inserted in the document.
- when unmarshalling a document, the token elements are stored before the content is unmarshalled. After the JAXB model has been created, the original token elements are inserted as Any types in the appropriate JAXB objects.

This had to be done because JAXB messes with token elements in a way that invalidates the digital signature, causing perfectly valid tokens to be rejected due to signature validation failure.

> Implement WS-T SAML Token Profile:: SAMLV2.0 validation
> -------------------------------------------------------
>
>                 Key: JBID-124
>                 URL: https://jira.jboss.org/jira/browse/JBID-124
>             Project: JBoss Identity
>          Issue Type: Sub-task
>          Components: Identity-Federation
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha3
>
>
> The SAML token provider must be able to validate the assertions it generates. This involves validating the digital signature and also the assertion validity period (lifetime).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 19:41:58 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Wed, 24 Jun 2009 19:41:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1667) MBeans cannot
 have heirarchical names
Message-ID: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>

MBeans cannot have heirarchical names
-------------------------------------

                 Key: JBMESSAGING-1667
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Destination Manager
    Affects Versions: 1.4.4.GA
         Environment: JBoss 5.1.0.GA
            Reporter: Richard Kennard
            Assignee: Tim Fox


In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:

<mbean code="..." name="...,name=app1/emails">

The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.

A workaround proposed on the forums is to use the 'JNDIName' attribute:

<mbean code="..." name="...,name=emails">
   <attribute name="JNDIName">app1/emails</attribute>

This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:

<mbean code="..." name="...,name=emails">
   <attribute name="JNDIName">app1/emails</attribute>

<mbean code="..." name="...,name=emails">
   <attribute name="JNDIName">app2/emails</attribute>

In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 17:45:07 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 24 Jun 2009 17:45:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-531) Build testsuite
 classpaths directly against jars in local maven repository
In-Reply-To: <6026725.1243637396349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23133015.1245879907715.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-531:
------------------------------

    Summary: Build testsuite classpaths directly against jars in local maven repository  (was: Build classpaths directly against jars in local maven repository)


> Build testsuite classpaths directly against jars in local maven repository
> --------------------------------------------------------------------------
>
>                 Key: JBBUILD-531
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-531
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the testsuite uses the jars in thirdparty.  Instead the paths in the testsuite should directly reference jars in the local maven repository directory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 15:18:59 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 24 Jun 2009 15:18:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7054) Allow configuring of
 Manager for distributable webapps via context.xml
Message-ID: <9414961.1245871139577.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow configuring of Manager for distributable webapps via context.xml
----------------------------------------------------------------------

                 Key: JBAS-7054
                 URL: https://jira.jboss.org/jira/browse/JBAS-7054
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-5.2.0.Beta1


TomcatDeployment will currently always replace the session Manager impl for contexts it creates if the distributable flag is set in web.xml.  Add a flag to TomcatDeployer disable this behavior. This will allow use of a Manager configured via context.xml.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 21:51:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 24 Jun 2009 21:51:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2140) Function + MVEL
 dialect == rule firing in error
Message-ID: <7739511.1245894717244.JavaMail.jira@cloud.prod.atl2.jboss.com>

Function + MVEL dialect == rule firing in error
-----------------------------------------------

                 Key: JBRULES-2140
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2140
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


REPORTED BY MICHAL:
---------------------------------------
Hi,

I've encountered a bizarre bug when a function is used together with a declared type and a rule with mvel dialect.

To reproduce create a default 'New Drools Project' in Eclipse and replace Sample.drl with the following:
--------------------------------------------------------------------------
package com.sample
 
function void aaa() { // <----- comment this and it will work
}

declare SomeBean
prop : int
end
 
rule "setup"
dialect "mvel"   // <----- comment this and it will work
when
eval(true)
then
SomeBean someBean = new SomeBean();
insert(someBean);
System.out.println( "setup inserted:" + someBean);
end

rule "should never fire"
salience -20
when
not SomeBean()
then
System.out.println( "rule that should never fire fired !!!" );
end
------------------------------------------------------------------------

Run the DroolsTest.java and see that the last rule that should never fire is actually fired. If you comment out the 'aaa' function or change the dialect to 'java' all works fine.

Note that it breaks on JDK 1.5.0_12 however it works fine on JDK 1.6.0_14.
Tested on WinXP.

Is it just my machine or does anybody else see this issue?

Best regards,
Michal


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jun 24 23:41:57 2009
From: jira-events at lists.jboss.org (Naresh Bhatia (JIRA))
Date: Wed, 24 Jun 2009 23:41:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBVFS-109) Trying to access
 all classpath
 resources from a web application fails due to VFS errors
In-Reply-To: <14030842.1241499346657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23174604.1245901317436.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBVFS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473709#action_12473709 ] 

Naresh Bhatia commented on JBVFS-109:
-------------------------------------

Thanks Marius. I tried out the solution and it works beautifully. Keep up the good work!

> Trying to access all classpath resources from a web application fails due to VFS errors
> ---------------------------------------------------------------------------------------
>
>                 Key: JBVFS-109
>                 URL: https://jira.jboss.org/jira/browse/JBVFS-109
>             Project: JBoss VFS
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.GA
>            Reporter: Marius Bogoevici
>            Assignee: Ales Justin
>             Fix For: 2.1.2.GA
>
>         Attachments: spring-jboss-jaxws.tar.gz
>
>
> The error has been triggered by using classpath scanning in Spring, but can be reproduced independently.
> The code in the servlet listed below does virtually the same thing as the VFSResourcePatternResolver:
> public class BasicServlet extends HttpServlet{
>     @Override
>     protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
>         ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
>         Enumeration<URL> urls = classLoader.getResources("");
>         StringBuffer buffer = new StringBuffer();
>         while (urls.hasMoreElements()) {
>             URL url = urls.nextElement();
>             VirtualFile file = VFS.getRoot(url);
>             buffer.append(file.getPathName() + "\n");
>         }
>         new PrintWriter(resp.getOutputStream()).println(buffer.toString());
>     }
> }
> Trying to access the servlet results in an error when one URL is converted to a VirtualFile by VFS.getRoot(), and here is the resulting exception. The URL that triggers the error differs if the test is repeated.
> 00:45:44,380 ERROR [[resource-servlet]] Servlet.service() for servlet resource-servlet threw exception
> java.io.IOException: Child not found opt/jboss/jboss-5.0.1.GA/server/default/deployers/jbossws.deployer/policy.jar/ for MemoryContextHandler at 555514482[path= context=vfsmemory://3j011-j4xs2m-fuc3y7a8-1-fuc3yl41-9 real=vfsmemory://3j011-j4xs2m-fuc3y7a8-1-fuc3yl41-9], available children: []
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.findHandler(DefaultVFSRegistry.java:109)
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:88)
> 	at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:121)
> 	at org.jboss.virtual.VFS.getRoot(VFS.java:276)
> 	at BasicServlet.doGet(BasicServlet.java:22)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 01:33:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 25 Jun 2009 01:33:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1667) MBeans
 cannot have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15959369.1245908036727.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1667:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 01:35:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 25 Jun 2009 01:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1667) MBeans cannot
 have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8049898.1245908156622.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1667:
------------------------------------

        Fix Version/s: 1.4.0.SP3.CP09
                       1.4.5.GA
    Affects Version/s: 1.4.0.SP3.CP08


> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 01:38:10 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jun 2009 01:38:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21000674.1245908290037.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reassigned JBDEPLOY-201:
---------------------------------------

    Assignee: Richard Opalka


> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 02:59:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 25 Jun 2009 02:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-214) fix matadata common
	build
In-Reply-To: <26514201.1245811874997.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29596414.1245913196461.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated JBMETA-214:
-------------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 1.0.2.Beta2)


Corrected the fix version.

> fix matadata common build
> -------------------------
>
>                 Key: JBMETA-214
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-214
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 2.0.0.CR1
>
>
> compile matadata/common in JDK5 will be failed
> [INFO] [compiler:compile]
> [INFO] Compiling 182 source files to /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/target/classes
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Compilation failure
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[29,20] package javax.xml.ws does not exist
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/WebServiceHandlerChainProcessor.java:[34,17] package javax.jws does not exist
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[70,69] cannot find symbol
> symbol  : class WebServiceRef
> location: class org.jboss.metadata.annotation.creator.ws.AbstractWebServiceRefProcessor<E>
> /home/jizhang/work/svn/jbossas/projects/metadata/common/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[99,55] cannot find symbol
> symbol  : class WebServiceRef
> location: class org.jboss.metadata.annotation.creator.ws.AbstractWebServiceRefProcessor<E>
> .....

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 03:01:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 25 Jun 2009 03:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-206) TESTSUITE:
 externalize schema to class mapping into a properties file
In-Reply-To: <10888381.1244726696753.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14537195.1245913316911.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated JBMETA-206:
-------------------------------------

    Fix Version/s: 2.0.0.CR1


> TESTSUITE: externalize schema to class mapping into a properties file
> ---------------------------------------------------------------------
>
>                 Key: JBMETA-206
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-206
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.0.2.Beta2, 2.0.0.CR1
>
>
> All the mapping is currently done in MetaDataSchemaResolverFactory. Working on the metadata split, this class could be in the common but the mapping would be different for a specific subproject.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 03:01:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 25 Jun 2009 03:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMETA-206) TESTSUITE:
 externalize schema to class mapping into a properties file
In-Reply-To: <10888381.1244726696753.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27963441.1245913316777.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky reopened JBMETA-206:
--------------------------------------



Re-openning to correct the fix version.

> TESTSUITE: externalize schema to class mapping into a properties file
> ---------------------------------------------------------------------
>
>                 Key: JBMETA-206
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-206
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.0.2.Beta2, 2.0.0.CR1
>
>
> All the mapping is currently done in MetaDataSchemaResolverFactory. Working on the metadata split, this class could be in the common but the mapping would be different for a specific subproject.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 03:01:57 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 25 Jun 2009 03:01:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-213) add JCA DTD files
In-Reply-To: <2485970.1245738836463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28419391.1245913317199.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated JBMETA-213:
-------------------------------------

    Fix Version/s: 2.0.0.CR1


> add JCA DTD files
> -----------------
>
>                 Key: JBMETA-213
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-213
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.2.Beta2, 2.0.0.CR1
>
>
> add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/rar

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 03:01:57 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 25 Jun 2009 03:01:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMETA-206) TESTSUITE:
 externalize schema to class mapping into a properties file
In-Reply-To: <10888381.1244726696753.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5874940.1245913317040.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBMETA-206.
------------------------------------

    Resolution: Done


> TESTSUITE: externalize schema to class mapping into a properties file
> ---------------------------------------------------------------------
>
>                 Key: JBMETA-206
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-206
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.0.2.Beta2, 2.0.0.CR1
>
>
> All the mapping is currently done in MetaDataSchemaResolverFactory. Working on the metadata split, this class could be in the common but the mapping would be different for a specific subproject.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 03:03:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 25 Jun 2009 03:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMETA-209) jboss-metadata
 trunk test compilation fails in JDK5
In-Reply-To: <9131641.1245260636508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31032264.1245913436448.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated JBMETA-209:
-------------------------------------

    Fix Version/s: 2.0.0.CR1


> jboss-metadata trunk test compilation fails in JDK5
> ---------------------------------------------------
>
>                 Key: JBMETA-209
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-209
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.0.2.Beta2, 2.0.0.CR1
>
>
> [INFO] Compilation failure
> /home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
> symbol  : method stringPropertyNames()
> location: class java.util.Properties
> /home/alrubinger/business/jboss/wc/jbossas/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/common/MetaDataSchemaResolverFactory.java:[81,37] cannot find symbol
> symbol  : method stringPropertyNames()
> location: class java.util.Properties

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 04:16:00 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 25 Jun 2009 04:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMETA-210) Validation errors in
 some jboss-___.5_x.xsd files
In-Reply-To: <21174263.1245266996482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23955424.1245917760623.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBMETA-210.
------------------------------------

    Fix Version/s: 1.0.2.Beta2
                   2.0.0.CR1
       Resolution: Done


Fixed. Thanks!

> Validation errors in some jboss-___.5_x.xsd files
> -------------------------------------------------
>
>                 Key: JBMETA-210
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-210
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Eclipse 3.4.2/WebToolsPlatform 3.0.4
>            Reporter: Wolfgang Knauf
>            Assignee: Alexey Loubyansky
>             Fix For: 1.0.2.Beta2, 2.0.0.CR1
>
>
> Some more schema definitions for 5.0/5.1 contain validation errors (which will raise validation errors if building instances in Eclipse). The problem is that includes/imports don't point to the web locations.
> The same issue arose for jboss-5.1.xsd: https://jira.jboss.org/jira/browse/JBMETA-200
> jboss-web_5_1.xsd:
>    <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>
>    <xsd:include schemaLocation="jboss-common_5_1.xsd"/>
> Change to:
>    <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>
>    <xsd:include schemaLocation="http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd"/>
> ===================    
> jboss-ds_5_0.xsd:
>    <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>
>    <xsd:include schemaLocation="jboss-common_5_1.xsd"/>
> Change to:
>    <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>
>    <xsd:include schemaLocation="http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd"/>
>    
> ===================    
> jboss-client_5_1.xsd
>    <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="javaee_5.xsd"/>
>    <xsd:include schemaLocation="jboss-common_5_1.xsd"/>
> Change to:
>    <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"/>
>    <xsd:include schemaLocation="http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd"/>
>    

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 04:34:08 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 25 Jun 2009 04:34:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1667) MBeans cannot
 have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30798819.1245918848307.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1667:
---------------------------------

    Issue Type: Feature Request  (was: Bug)


> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 04:36:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 25 Jun 2009 04:36:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1667) MBeans
 cannot have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18924926.1245919016903.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473722#action_12473722 ] 

Tim Fox commented on JBMESSAGING-1667:
--------------------------------------

Most messaging systems use the dot '.' not the slash to separate words in hierarchical topics.

This is what I recommend you do, which will already work with JBM 1.x

<mbean code="..." name="...,name=app1.emails">
   <attribute name="JNDIName">app1/emails</attribute> 

<mbean code="..." name="...,name=app2.emails">
   <attribute name="JNDIName">app2/emails</attribute> 

<mbean code="..." name="...,name=app3.subapp2..emails">
   <attribute name="JNDIName">app1/subapp2/emails</attribute> 

> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 04:45:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 25 Jun 2009 04:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23936305.1245919556696.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-201.
----------------------------------

    Resolution: Rejected


> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 04:53:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 25 Jun 2009 04:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1667) MBeans
 cannot have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11174749.1245920036536.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473726#action_12473726 ] 

Tim Fox commented on JBMESSAGING-1667:
--------------------------------------

JBM, ActiveMQ, also any AMQP based system will use dots. JBM 2.0 uses dots too. (see http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/usermanual-2.0.0.beta3/html/wildcard-routing.html )

Using slashes won't allow you to exploit wildcard routing in JBM 2.0 (or ActiveMQ or many other systems for that matter).

I recommend for this task we keep the behaviour as is and explicitly disallow the forward slash character in destination names. We can throw a warning on deploy and not deploy them if they contain the forward slash character.

I am loathed to give special status to the forward slash character that would make it create subcontextes automatically since this goes against the grain of normal conventions for topic hierarchies.

> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 04:59:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 25 Jun 2009 04:59:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1667) MBeans
 cannot have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31953395.1245920396574.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473727#action_12473727 ] 

Howard Gao commented on JBMESSAGING-1667:
-----------------------------------------

I agree with Tim. 

Howard


> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:18:09 2009
From: jira-events at lists.jboss.org (Michal Bali (JIRA))
Date: Thu, 25 Jun 2009 05:18:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2140) Function + MVEL
 dialect == rule firing in error
In-Reply-To: <7739511.1245894717244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27819240.1245921489247.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473729#action_12473729 ] 

Michal Bali commented on JBRULES-2140:
--------------------------------------

I am not sure if this helps but the example works fine with SNAPSHOT taken at the following time:
drools-core-5.0.0.20090417.044049-485.jar

> Function + MVEL dialect == rule firing in error
> -----------------------------------------------
>
>                 Key: JBRULES-2140
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2140
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> REPORTED BY MICHAL:
> ---------------------------------------
> Hi,
> I've encountered a bizarre bug when a function is used together with a declared type and a rule with mvel dialect.
> To reproduce create a default 'New Drools Project' in Eclipse and replace Sample.drl with the following:
> --------------------------------------------------------------------------
> package com.sample
>  
> function void aaa() { // <----- comment this and it will work
> }
> declare SomeBean
> prop : int
> end
>  
> rule "setup"
> dialect "mvel"   // <----- comment this and it will work
> when
> eval(true)
> then
> SomeBean someBean = new SomeBean();
> insert(someBean);
> System.out.println( "setup inserted:" + someBean);
> end
> rule "should never fire"
> salience -20
> when
> not SomeBean()
> then
> System.out.println( "rule that should never fire fired !!!" );
> end
> ------------------------------------------------------------------------
> Run the DroolsTest.java and see that the last rule that should never fire is actually fired. If you comment out the 'aaa' function or change the dialect to 'java' all works fine.
> Note that it breaks on JDK 1.5.0_12 however it works fine on JDK 1.6.0_14.
> Tested on WinXP.
> Is it just my machine or does anybody else see this issue?
> Best regards,
> Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:21:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jun 2009 05:21:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16166539.1245921716760.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reopened JBDEPLOY-201:
-------------------------------------



Just give me free hands Ales, please.
I'll fix it because it's blocking issue for me.
I know how to fix it;) You can review my
commits afterwards.

> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:23:57 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jun 2009 05:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26215070.1245921837233.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated JBDEPLOY-201:
------------------------------------

    Comment: was deleted


> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:52:59 2009
From: jira-events at lists.jboss.org (Vicky Kak (JIRA))
Date: Thu, 25 Jun 2009 05:52:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCOMMON-35) NestedThrowable
 Class when accessed concurrently by 2 Threads cause deadlock .
In-Reply-To: <7851949.1191329943789.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15353220.1245923579178.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBCOMMON-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vicky Kak updated JBCOMMON-35:
------------------------------

    Fix Version/s: 1.2.1.GA


> NestedThrowable Class when accessed concurrently by 2 Threads cause deadlock .
> ------------------------------------------------------------------------------
>
>                 Key: JBCOMMON-35
>                 URL: https://jira.jboss.org/jira/browse/JBCOMMON-35
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common-core (2.x), common-old (1.x)
>    Affects Versions: 1.0.0.GA
>            Reporter: Vicky Kak
>            Assignee: Vicky Kak
>             Fix For: 1.2.1.GA, 1.2.2.GA, 1.0.5.GA
>
>
> http://forum.java.sun.com/thread.jspa?threadID=752201

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:54:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 25 Jun 2009 05:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1851) Investigate the
 failure
 org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
In-Reply-To: <10648726.1245161216783.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18970301.1245923696571.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1851.
------------------------------------

                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-metrics-deployer:1.0.0-alpha-11


The test is now passing on mike (starting job#347) after upgrading to jboss-ejb3-metrics-deployer:1.0.0-alpha-11

> Investigate the failure org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
> -------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1851
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1851
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: metrics-deployer, testsuite
>    Affects Versions: 1.1.7
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> The org.jboss.ejb3.test.container.unit.ContainerTestCase consistently fails with:
> javax.naming.NameNotFoundException: Stateful not bound
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
> 	at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
> 	at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> 	at java.lang.Thread.run(Thread.java:595)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> 	at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at org.jboss.ejb3.test.container.unit.ContainerTestCase.testInvocationStatistics(ContainerTestCase.java:93)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
> 	at junit.extensions.TestSetup.run(TestSetup.java:27)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:58:57 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Thu, 25 Jun 2009 05:58:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1612) Provide a
 complete JCA Parmeters override
In-Reply-To: <23605475.1241104013618.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25026705.1245923937230.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1612.
------------------------------------

    Resolution: Done


> Provide a complete JCA Parmeters override
> -----------------------------------------
>
>                 Key: JBMESSAGING-1612
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1612
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 06:46:11 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 25 Jun 2009 06:46:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1001) Use ByteMan /
 Metronome to inject faults for testing
Message-ID: <18204662.1245926771912.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use ByteMan / Metronome to inject faults for testing
----------------------------------------------------

                 Key: JGRP-1001
                 URL: https://jira.jboss.org/jira/browse/JGRP-1001
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


Use ByteMan (jboss.org/byteman) to simulate issues that can happen at runtime: do this in unit tests.
For example: crash of merge leader after initial round (who frees the locks ?) (same for FLUSH)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 06:47:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 25 Jun 2009 06:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13127312.1245926876523.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473749#action_12473749 ] 

Ales Justin commented on JBDEPLOY-201:
--------------------------------------

Can you please not commit before we discuss this on the MC dev forum?
(currently the discussion is on the MC user forum, and you haven't given me any valid arguments)

> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 07:17:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jun 2009 07:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17890110.1245928676642.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473757#action_12473757 ] 

Richard Opalka commented on JBDEPLOY-201:
-----------------------------------------

Sorry for that. I thought I posted it to dev MC forum :(
That explains why I didn't get the notification on your comments.
I'm moving the discussion to the MC dev forum.

> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 07:17:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jun 2009 07:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5360829.1245928676900.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473758#action_12473758 ] 

Richard Opalka commented on JBDEPLOY-201:
-----------------------------------------

Related user forum discussion: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239756

> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 07:23:00 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jun 2009 07:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21051641.1245928980797.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated JBDEPLOY-201:
------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239981  (was: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239756)


> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 08:09:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 25 Jun 2009 08:09:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2136) Simple match
 rule fails on 5.0.1 and works on 4.0.7
In-Reply-To: <17964558.1245745317053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20935041.1245931797374.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned JBRULES-2136:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> Simple match rule fails on 5.0.1 and works on 4.0.7
> ---------------------------------------------------
>
>                 Key: JBRULES-2136
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2136
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Corneil du Plessis
>            Assignee: Edson Tirelli
>            Priority: Critical
>         Attachments: drools-test.zip
>
>
> A simple rule that worked in 4.0.7 fails in 5.0.1
> An Eclipse project to illustrate the problem will be attached to this issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 08:09:57 2009
From: jira-events at lists.jboss.org (Nicolas Heron (JIRA))
Date: Thu, 25 Jun 2009 08:09:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2141) In a rule flow,
 when the action is in MVEL, it is not possible to import classes
Message-ID: <5800231.1245931797780.JavaMail.jira@cloud.prod.atl2.jboss.com>

In a rule flow, when the action is in MVEL, it is not possible to import classes
--------------------------------------------------------------------------------

                 Key: JBRULES-2141
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2141
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse (flow)
    Affects Versions: FUTURE
            Reporter: Nicolas Heron
            Assignee: Mark Proctor


example : 
-----------
Long montant = (Long)context.getVariable("surimposition");
System.out.println ("Surimposition : '" + montant + "'");
 filter = new org.drools.runtime.ClassObjectFilter (fr.sopra.impot.Impot.class);
java.util.Collection impots = context.getKnowledgeRuntime().getObjects(filter);
if (impots.size()==1) {
	Impot impot = (Impot)impots.toArray()[0]; 
	impot.setMontantRedressement(montant);
}
---------------
it says  at design time : 
Process 'ImpotProcess' [fr.sopra.impot.ImpotProcess]: Action node 'Traitement des resultats' [13] has invalid action: was expecting type: java.lang.Object; but found type: null.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 08:17:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 25 Jun 2009 08:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2136) Simple match rule
 fails on 5.0.1 and works on 4.0.7
In-Reply-To: <17964558.1245745317053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15029106.1245932276540.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2136.
----------------------------------

    Resolution: Rejected


Due to some limitations on the way that Drools 4 handles regexps, we had to change the default escaping syntax for regexps, from single escape to double escape. In Drools 5, regexps work exactly like in Java. So, instead of doing:

".*\s(ADDR)\s.*|(ADDR)\s.*|.*\s(ADDR)"

You need to write:

".*\\s(ADDR)\\s.*|(ADDR)\\s.*|.*\\s(ADDR)"

If you would like to continue using regexps in the same way you did for Drools 4, i.e., with single escape (not recommended), there is a configuration that makes Drools 5 parse regexps as it did in Drools 4.
Using the type safe API, you can do:

        KnowledgeBuilderConfiguration config = KnowledgeBuilderFactory.newKnowledgeBuilderConfiguration();
        config.setOption( ProcessStringEscapesOption.NO);
        KnowledgeBuider kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder( conf );

If you prefer to use the property or configuration file, then it is:

drools.parser.processStringEscapes = false



> Simple match rule fails on 5.0.1 and works on 4.0.7
> ---------------------------------------------------
>
>                 Key: JBRULES-2136
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2136
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Corneil du Plessis
>            Assignee: Edson Tirelli
>            Priority: Critical
>         Attachments: drools-test.zip
>
>
> A simple rule that worked in 4.0.7 fails in 5.0.1
> An Eclipse project to illustrate the problem will be attached to this issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 08:32:56 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 25 Jun 2009 08:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24592319.1245933176587.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin reassigned JBDEPLOY-201:
------------------------------------

    Assignee: Ales Justin  (was: Richard Opalka)


> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Ales Justin
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 08:40:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 25 Jun 2009 08:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1812) @Service beans
 with a @Management interface leave orphan MC beans after undeploy
In-Reply-To: <24300925.1240836886520.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13707683.1245933656519.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1812.
------------------------------------

    Resolution: Out of Date


This is no longer reproducible against JBoss AS 5.1.0 GA. Please upgrade to AS 5.1.0 GA and if you still run into this issue, please bring this up in the forum thread so that we can decide about re-opening this.


> @Service beans with a @Management interface leave orphan MC beans after undeploy
> --------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1812
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1812
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.4
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> If a @Service bean is marked to have a @Management interface, during deployment a MBean is created as well as a MC bean is deployed. However on undeployment, only the MBean is unregistered, leaving back the MC bean. This leads to MC complaining about incomplete deployments due to missing dependencies. Please see the refered forum thread for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 08:50:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jun 2009 08:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22581236.1245934256518.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473777#action_12473777 ] 

Richard Opalka commented on JBDEPLOY-201:
-----------------------------------------

The fix have to include also the following usecase:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157558&postdays=0&postorder=asc&start=10#4239932
and throw exception when such attempt is detected.

> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Ales Justin
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 09:35:58 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 25 Jun 2009 09:35:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6624) EJB3 Session Bean
	metrics
In-Reply-To: <33127819.1237195628532.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28062914.1245936958146.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-6624.
---------------------------------------

    Resolution: Done


> EJB3 Session Bean metrics
> -------------------------
>
>                 Key: JBAS-6624
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6624
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3, Management services
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> EJB3 Session Bean metrics (in addition to availability)
>        <!-- ear=rhq.ear,jar=rhq-enterprise-server-ejb.ejb3,name=AgentManagerBean,service=EJB3 -->
>          <!-- jboss.j2ee:jar=SimpleSLSB.jar,name=SimpleSLSB,service=EJB3 -->
>         <metric displayName="Current Count" property="CurrentSize"/>
>          <metric displayName="Create Count" property="CreateCount" displayType="summary" measurementType="trendsup"
>                  description="the number of instances of this EJB that have been created"/>
>          <metric displayName="Remove Count" property="RemoveCount" displayType="summary" measurementType="trendsup"
>                  description="the number of instances of this EJB that have been removed"/>
>          <metric displayName="Available Count" property="AvailableCount"/>
>          <metric displayName="Max Size" property="MaxSize"/>
> Plus the complex method invocation metrics
>  <metric property="InvokeStats" dataType="calltime" units="milliseconds"
>                  defaultOn="false" defaultInterval="600000" destinationType="Method Name"
>                  description="the minimum, maximum, and average invocation times for each of the methods exposed by this EJB;
>                               NOTE: this metric is only available if JBoss EJB3 RC9 Patch 1 or later is being used
>                               (a capable version of EJB3 is included with JBossAS 4.2.0.GA or later)"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 09:37:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 25 Jun 2009 09:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6999) expose MOs for EJB3
 MDBs w/ some metrics
In-Reply-To: <23501033.1244041905722.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13371911.1245937076612.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-6999.
---------------------------------------

    Resolution: Done


> expose MOs for EJB3 MDBs w/ some metrics
> ----------------------------------------
>
>                 Key: JBAS-6999
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6999
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> <pilhuhn> Do you also plan to list MDBs so that they can at least be detected?
> <ALR> pilhuhn: I hadn't, but I can add that.  What would you like exposed for MDB?
> <pilhuhn> metrics like on the jmx console would be cool, but just listing them as ManagedComponent within a EJB jar would be great - they are already in the KnownComponentTypes :)
> <ALR> pilhuhn: To list as a ManagedComponent wouldn't I need to register some @ManagementObject ?  Just some stub thing?
> <pilhuhn> aehm .. :)
> <ALR> pilhuhn: I've found some stats I can expose, actually, without touching the ejb3-core, which has been my aim thus far. :)  I'll do it.
> <pilhuhn> Great - JOPR-203 has a EAR attached with a MDB in it - and the jxm-console shows keepalive millis, stats, min pool size, max pool size, delivery active and max messages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 10:49:56 2009
From: jira-events at lists.jboss.org (jorge middleton (JIRA))
Date: Thu, 25 Jun 2009 10:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2142) import resources
 from Guvnor facilities
Message-ID: <11004318.1245941396633.JavaMail.jira@cloud.prod.atl2.jboss.com>

import resources from Guvnor facilities
---------------------------------------

                 Key: JBRULES-2142
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2142
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
    Affects Versions: 5.0.0.CR1
         Environment: windows
            Reporter: jorge middleton
            Assignee: Mark Proctor
            Priority: Minor


The import facility has not have the posibility to import the complete package even more the posibility to import more than one package. I try to import a complete package but I couldn't because the package also had *.jar files.

Another improvenment is when you have to select where to download the resources previously selected. The window show me all my eclipse projects even those that are closed.

Thanks in advance and sorry for my english.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 11:18:58 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 25 Jun 2009 11:18:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1002) Merge: make the
 coordinator remain the same if possible after a merge
Message-ID: <27996130.1245943138592.JavaMail.jira@cloud.prod.atl2.jboss.com>

Merge: make the coordinator remain the same if possible after a merge
---------------------------------------------------------------------

                 Key: JGRP-1002
                 URL: https://jira.jboss.org/jira/browse/JGRP-1002
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.0


When we have {C, A, B} and split into {C,A} and {B}, then a merge will produce {A,B,C}. Therefore the coord is moved from C to A. For certain apps, e.g. JBoss singletons, this is not good, as we're moving the singleton services from a perfectly healthy node to a different node.
GOAL: come up with a deterministic policy of picking a coord such that we minimize coord switching if the existing coord is still member of the cluster.
This depends on or is related to the flexible coord pick policy JIRA issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:12:08 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Thu, 25 Jun 2009 15:12:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1856) NPE if
 "res-type" element is
 missing in ejb-jar.xml for injection of SessionContext
Message-ID: <8850904.1245957128139.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE if "res-type" element is missing in ejb-jar.xml for injection of SessionContext
-----------------------------------------------------------------------------------

                 Key: EJBTHREE-1856
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1856
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: 1.1.5
            Reporter: Wolfgang Knauf


I have an ejb-jar.xml for an annotation free EJB. I try to inject a SessionContext.

With JBoss 5.0, this snippet worked:
			<resource-ref>
				<res-ref-name>NameDoesNotCare</res-ref-name>
				<mapped-name>java:comp/EJBContext</mapped-name>
				<injection-target>
					<injection-target-class>de.some.package.SecuredBean</injection-target-class>
					<injection-target-name>mySessionContext</injection-target-name>
			  	</injection-target>
			</resource-ref>

With JBoss 5.1, this fails with a NullPointerException (EJB is "SecuredBean" in "SecurityEJB.jar"):

21:02:02,890 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
21:02:02,890 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/C:/temp/jboss-5.1.0.GA/server/default/tmp/jsr88/Security.ear/ state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying SecurityEJB.jar: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
	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:1210)
	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.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:413)
	at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.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 sun.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
	at sun.reflect.GeneratedMethodAccessor304.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
	at sun.reflect.GeneratedMethodAccessor303.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
	at sun.rmi.transport.Transport$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Unknown Source)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.Exception: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
	... 68 more
Caused by: java.lang.NullPointerException
	at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185)
	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335)
	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588)
	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
	... 69 more


I found that "<res-type>javax.ejb.SessionContext</res-type>" is missing. I think the deployment should raise a meaningful error message.

I can provide you with a full sample if required.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:15:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 25 Jun 2009 15:15:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1856) NPE if
 "res-type" element
 is missing in ejb-jar.xml for injection of SessionContext
In-Reply-To: <8850904.1245957128139.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18288686.1245957356994.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473820#action_12473820 ] 

jaikiran pai commented on EJBTHREE-1856:
----------------------------------------

Wolfgang, if you have that sample application, please attach it to the JIRA. Thanks :)

> NPE if "res-type" element is missing in ejb-jar.xml for injection of SessionContext
> -----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1856
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1856
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.5
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>
> I have an ejb-jar.xml for an annotation free EJB. I try to inject a SessionContext.
> With JBoss 5.0, this snippet worked:
> 			<resource-ref>
> 				<res-ref-name>NameDoesNotCare</res-ref-name>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.some.package.SecuredBean</injection-target-class>
> 					<injection-target-name>mySessionContext</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> With JBoss 5.1, this fails with a NullPointerException (EJB is "SecuredBean" in "SecurityEJB.jar"):
> 21:02:02,890 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 21:02:02,890 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/C:/temp/jboss-5.1.0.GA/server/default/tmp/jsr88/Security.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying SecurityEJB.jar: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
> 	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:1210)
> 	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.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:413)
> 	at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.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 sun.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	at sun.reflect.GeneratedMethodAccessor304.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.GeneratedMethodAccessor303.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> 	at sun.rmi.transport.Transport$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
> 	... 68 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
> 	... 69 more
> I found that "<res-type>javax.ejb.SessionContext</res-type>" is missing. I think the deployment should raise a meaningful error message.
> I can provide you with a full sample if required.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:15:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 25 Jun 2009 15:15:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1856) NPE if
 "res-type" element is
 missing in ejb-jar.xml for injection of SessionContext
In-Reply-To: <8850904.1245957128139.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8221220.1245957356793.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1856:
--------------------------------------

    Assignee: jaikiran pai


> NPE if "res-type" element is missing in ejb-jar.xml for injection of SessionContext
> -----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1856
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1856
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.5
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>
> I have an ejb-jar.xml for an annotation free EJB. I try to inject a SessionContext.
> With JBoss 5.0, this snippet worked:
> 			<resource-ref>
> 				<res-ref-name>NameDoesNotCare</res-ref-name>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.some.package.SecuredBean</injection-target-class>
> 					<injection-target-name>mySessionContext</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> With JBoss 5.1, this fails with a NullPointerException (EJB is "SecuredBean" in "SecurityEJB.jar"):
> 21:02:02,890 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 21:02:02,890 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/C:/temp/jboss-5.1.0.GA/server/default/tmp/jsr88/Security.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying SecurityEJB.jar: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
> 	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:1210)
> 	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.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:413)
> 	at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.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 sun.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	at sun.reflect.GeneratedMethodAccessor304.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.GeneratedMethodAccessor303.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> 	at sun.rmi.transport.Transport$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
> 	... 68 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
> 	... 69 more
> I found that "<res-type>javax.ejb.SessionContext</res-type>" is missing. I think the deployment should raise a meaningful error message.
> I can provide you with a full sample if required.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:17:57 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 25 Jun 2009 15:17:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1856) NPE if
 "res-type" element is
 missing in ejb-jar.xml for injection of SessionContext
In-Reply-To: <8850904.1245957128139.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7479888.1245957477120.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1856:
-----------------------------------

    Component/s: core


> NPE if "res-type" element is missing in ejb-jar.xml for injection of SessionContext
> -----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1856
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1856
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>
> I have an ejb-jar.xml for an annotation free EJB. I try to inject a SessionContext.
> With JBoss 5.0, this snippet worked:
> 			<resource-ref>
> 				<res-ref-name>NameDoesNotCare</res-ref-name>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.some.package.SecuredBean</injection-target-class>
> 					<injection-target-name>mySessionContext</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> With JBoss 5.1, this fails with a NullPointerException (EJB is "SecuredBean" in "SecurityEJB.jar"):
> 21:02:02,890 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 21:02:02,890 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/C:/temp/jboss-5.1.0.GA/server/default/tmp/jsr88/Security.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying SecurityEJB.jar: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
> 	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:1210)
> 	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.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:413)
> 	at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.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 sun.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	at sun.reflect.GeneratedMethodAccessor304.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.GeneratedMethodAccessor303.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> 	at sun.rmi.transport.Transport$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
> 	... 68 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
> 	... 69 more
> I found that "<res-type>javax.ejb.SessionContext</res-type>" is missing. I think the deployment should raise a meaningful error message.
> I can provide you with a full sample if required.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:27:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Thu, 25 Jun 2009 15:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1856) NPE if
 "res-type" element
 is missing in ejb-jar.xml for injection of SessionContext
In-Reply-To: <8850904.1245957128139.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18959750.1245958076707.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473821#action_12473821 ] 

Wolfgang Knauf commented on EJBTHREE-1856:
------------------------------------------

You will find a working app here:
http://www.informatik.fh-wiesbaden.de/~knauf/KomponentenArchitekturen2008/security/SecurityNoAnnotation.ear
Simply remove the "res-type" line in ejb-jar.xml

I can modify it and attach it "broken" here if necessary, but this might take some days until I find the time ;-).

> NPE if "res-type" element is missing in ejb-jar.xml for injection of SessionContext
> -----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1856
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1856
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>
> I have an ejb-jar.xml for an annotation free EJB. I try to inject a SessionContext.
> With JBoss 5.0, this snippet worked:
> 			<resource-ref>
> 				<res-ref-name>NameDoesNotCare</res-ref-name>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.some.package.SecuredBean</injection-target-class>
> 					<injection-target-name>mySessionContext</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> With JBoss 5.1, this fails with a NullPointerException (EJB is "SecuredBean" in "SecurityEJB.jar"):
> 21:02:02,890 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 21:02:02,890 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/C:/temp/jboss-5.1.0.GA/server/default/tmp/jsr88/Security.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying SecurityEJB.jar: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
> 	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:1210)
> 	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.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:413)
> 	at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.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 sun.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	at sun.reflect.GeneratedMethodAccessor304.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.GeneratedMethodAccessor303.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> 	at sun.rmi.transport.Transport$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
> 	... 68 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
> 	... 69 more
> I found that "<res-type>javax.ejb.SessionContext</res-type>" is missing. I think the deployment should raise a meaningful error message.
> I can provide you with a full sample if required.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:29:56 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 25 Jun 2009 15:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2140) Function + MVEL
 dialect == rule firing in error
In-Reply-To: <7739511.1245894717244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24783117.1245958196561.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473822#action_12473822 ] 

Edson Tirelli commented on JBRULES-2140:
----------------------------------------

Ok, I found the problem. It was a classloader problem.

What happens is that generated types (like SomeBean in the example) are stored in the JavaDialectRuntimeData. 

When the package is added to a knowledgebase, the engine wires all types and classloaders to the respective classloaders used by the knowledgebase. So, the mvel consequence of the rule is wired against the java dialect classloader and everything works. 

Now, the presence of a function in the package forces a rewiring on the dialect data. Unfortunately, the re-wiring requires that a new classloader is created for the java dialect. By a hashcode coincidence, the re-wiring happens first on the mvel dialect and later on the java dialect. So, while the java dialect is using a new classloader, the mvel dialect was still referencing the old classloader. So the bean class in the mvel consequence was still using the old classloader, and not matching anything else in the rulebase.

Anyway, to fix this, since Java is our main dialect, I fixed the order of the rewiring to always be: java first, and then all other dialects.

I am running a full build now and will commit right after that.

Thanks for reporting and providing test case.

> Function + MVEL dialect == rule firing in error
> -----------------------------------------------
>
>                 Key: JBRULES-2140
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2140
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> REPORTED BY MICHAL:
> ---------------------------------------
> Hi,
> I've encountered a bizarre bug when a function is used together with a declared type and a rule with mvel dialect.
> To reproduce create a default 'New Drools Project' in Eclipse and replace Sample.drl with the following:
> --------------------------------------------------------------------------
> package com.sample
>  
> function void aaa() { // <----- comment this and it will work
> }
> declare SomeBean
> prop : int
> end
>  
> rule "setup"
> dialect "mvel"   // <----- comment this and it will work
> when
> eval(true)
> then
> SomeBean someBean = new SomeBean();
> insert(someBean);
> System.out.println( "setup inserted:" + someBean);
> end
> rule "should never fire"
> salience -20
> when
> not SomeBean()
> then
> System.out.println( "rule that should never fire fired !!!" );
> end
> ------------------------------------------------------------------------
> Run the DroolsTest.java and see that the last rule that should never fire is actually fired. If you comment out the 'aaa' function or change the dialect to 'java' all works fine.
> Note that it breaks on JDK 1.5.0_12 however it works fine on JDK 1.6.0_14.
> Tested on WinXP.
> Is it just my machine or does anybody else see this issue?
> Best regards,
> Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:34:09 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 25 Jun 2009 15:34:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2140) Function + MVEL
 dialect == rule firing in error
In-Reply-To: <7739511.1245894717244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7308320.1245958449171.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2140.
----------------------------------

    Resolution: Done


Fixed and committed to revision #27136.

Let me know if you still see any related problem.

Thanks,
Edson

> Function + MVEL dialect == rule firing in error
> -----------------------------------------------
>
>                 Key: JBRULES-2140
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2140
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> REPORTED BY MICHAL:
> ---------------------------------------
> Hi,
> I've encountered a bizarre bug when a function is used together with a declared type and a rule with mvel dialect.
> To reproduce create a default 'New Drools Project' in Eclipse and replace Sample.drl with the following:
> --------------------------------------------------------------------------
> package com.sample
>  
> function void aaa() { // <----- comment this and it will work
> }
> declare SomeBean
> prop : int
> end
>  
> rule "setup"
> dialect "mvel"   // <----- comment this and it will work
> when
> eval(true)
> then
> SomeBean someBean = new SomeBean();
> insert(someBean);
> System.out.println( "setup inserted:" + someBean);
> end
> rule "should never fire"
> salience -20
> when
> not SomeBean()
> then
> System.out.println( "rule that should never fire fired !!!" );
> end
> ------------------------------------------------------------------------
> Run the DroolsTest.java and see that the last rule that should never fire is actually fired. If you comment out the 'aaa' function or change the dialect to 'java' all works fine.
> Note that it breaks on JDK 1.5.0_12 however it works fine on JDK 1.6.0_14.
> Tested on WinXP.
> Is it just my machine or does anybody else see this issue?
> Best regards,
> Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 15:57:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 25 Jun 2009 15:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7056) Update to JBoss AOP
	2.1.3.GA
Message-ID: <4474870.1245959876452.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update to JBoss AOP 2.1.3.GA
----------------------------

                 Key: JBAS-7056
                 URL: https://jira.jboss.org/jira/browse/JBAS-7056
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Shelly McGowan
            Assignee: Shelly McGowan




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 16:02:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 25 Jun 2009 16:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7057) Update Kernel to
	2.0.8.GA
Message-ID: <28464517.1245960176528.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update Kernel to 2.0.8.GA
-------------------------

                 Key: JBAS-7057
                 URL: https://jira.jboss.org/jira/browse/JBAS-7057
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Shelly McGowan
            Assignee: Shelly McGowan




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:54:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 25 Jun 2009 05:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1851) Investigate the
 failure
 org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
In-Reply-To: <10648726.1245161216783.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7617255.1245923696741.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1851:
-----------------------------------

    Component/s: metrics-deployer


> Investigate the failure org.jboss.ejb3.test.container.unit.ContainerTestCase testcase
> -------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1851
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1851
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: metrics-deployer, testsuite
>    Affects Versions: 1.1.7
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> The org.jboss.ejb3.test.container.unit.ContainerTestCase consistently fails with:
> javax.naming.NameNotFoundException: Stateful not bound
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
> 	at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
> 	at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> 	at java.lang.Thread.run(Thread.java:595)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> 	at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at org.jboss.ejb3.test.container.unit.ContainerTestCase.testInvocationStatistics(ContainerTestCase.java:93)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
> 	at junit.extensions.TestSetup.run(TestSetup.java:27)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 05:56:56 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Thu, 25 Jun 2009 05:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1642) Make the java
 ee example runnable on windows
In-Reply-To: <22235800.1244482856551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22559502.1245923816680.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1642.
------------------------------------

    Resolution: Done


> Make the java ee example runnable on windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-1642
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1642
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>         Attachments: build.xml
>
>
> The javaee examples are hard-coded for Linux (run.sh is used to start JBoss AS).
> For windows users, they have to manually edit the build files to sue run.bat instead.
> There is a note in the Beta1 release notes about that.
> The windows/linux difference should be parameterized so that the same build file
> could be used on both OSes.
> The windows file (*.bat) must also be checked to ensure they ends with  \r\n

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 17:28:56 2009
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Thu, 25 Jun 2009 17:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1000) COMPRESS corrupts
	some messages
In-Reply-To: <7560851.1245854756549.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2142637.1245965336591.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473830#action_12473830 ] 

Dennis Reed commented on JGRP-1000:
-----------------------------------

If I'm reading the RFCs and the compressed data correctly, the size of the compressed message is:

    ZLIB data: - 6 bytes (no DICTID)
    Compressed data - worst case is original size plus 5 bytes per 32K block

So the maximum buffer size needed would be something like: length + ( 5 * ( length / 32768 ) ) + 11
(the / is integer division)

References:
http://www.isi.edu/in-notes/rfc1950.txt
http://www.isi.edu/in-notes/rfc1951.txt

> COMPRESS corrupts some messages
> -------------------------------
>
>                 Key: JGRP-1000
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1000
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.5
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>
> COMPRESS.down() stores the compressed message in a temporary buffer the same size as the original message.
> If the compressed size of a message is larger than the original, then part of the message is lost, with no errors reported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 18:28:57 2009
From: jira-events at lists.jboss.org (Damon Horrell (JIRA))
Date: Thu, 25 Jun 2009 18:28:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2129) The
 WorkingMemoryEventListener doesn't set the oldObject for objectUpdated
 method.
In-Reply-To: <5650920.1245368156655.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5594939.1245968937376.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473837#action_12473837 ] 

Damon Horrell commented on JBRULES-2129:
----------------------------------------

This class is now called ObjectUpdatedEventImpl.  The bug still exists.

> The WorkingMemoryEventListener doesn't set the oldObject for objectUpdated method.
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2129
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2129
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.1.0.M1
>            Reporter: John Bebbington
>            Assignee: Mark Proctor
>
> The org.drools.event.rule.impl.ObjectEventImpl.java class has a fairly obvious error in it's constructor.
> The line:
>        object = event.getOldObject();
> Needs to be changed to:
>        oldObject = event.getOldObject();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 20:57:56 2009
From: jira-events at lists.jboss.org (murray armfield (JIRA))
Date: Thu, 25 Jun 2009 20:57:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6372) Add data source
 configuration files for Ingres RDBMS support
In-Reply-To: <3379588.1231456084356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28173076.1245977876915.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

murray armfield updated JBAS-6372:
----------------------------------

    Attachment: JBAS-ingres.tar.gz


Please disregard all previous file uploads. This is the current one to use.

> Add data source configuration files for Ingres RDBMS support
> ------------------------------------------------------------
>
>                 Key: JBAS-6372
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6372
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1, JBossAS-6.0.0.Alpha1, JBossAS-Branch_4_2
>         Environment: N/A
>            Reporter: murray armfield
>            Priority: Optional
>         Attachments: create_database.sql, create_database.sql, JBAS-ingres.tar.gz, jboss-soa-p.4.3.0.tar.gz
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> I'm working on getting JBoss going against the Ingres RDBMS database server. I've got some initial config files that can be included as part of the data source configurations. I have other patches for different components, but this issue is just to get two data source definitions added to the jbossas/trunk/connector/src/etc/example-config directory, one for a  local-tx-datasource and one for a xa-datasource.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 21:02:56 2009
From: jira-events at lists.jboss.org (murray armfield (JIRA))
Date: Thu, 25 Jun 2009 21:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6372) Add data source
 configuration files for Ingres RDBMS support
In-Reply-To: <3379588.1231456084356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17911441.1245978176502.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473841#action_12473841 ] 

murray armfield commented on JBAS-6372:
---------------------------------------

Hi Folks,
   I have been working around this for some time and have put together a better set of files for inclusion as JBoss AS.

   Please disregard all previous uploads except  JBAS-ingres.tar.gz. Although this is the most recent upload, it is not the last one in the list of downloads.

   In this tarball, there are the datasource templates for using Ingres and the messaging configuration file for Ingres. Additionally, Ingres use requires an updated CMP from what has been shipping in JBoss AS for some time now. I have included a copy of standardjbosscmp-jdbc.xml which has the current updated CMP for use with Ingres. Using this CMP means that all the other files that used to be part of this jIRA are no longer necessary.

    As an aside, the old download jboss-soa-p.4.3.0.tar.gz does have the ingres versions/files for what is distributed with JBoss SOA to make use of the automatic database reconfiguration scripts if your interested/can use them.

Take care,
    Murray

> Add data source configuration files for Ingres RDBMS support
> ------------------------------------------------------------
>
>                 Key: JBAS-6372
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6372
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1, JBossAS-6.0.0.Alpha1, JBossAS-Branch_4_2
>         Environment: N/A
>            Reporter: murray armfield
>            Priority: Optional
>         Attachments: create_database.sql, create_database.sql, JBAS-ingres.tar.gz, jboss-soa-p.4.3.0.tar.gz
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> I'm working on getting JBoss going against the Ingres RDBMS database server. I've got some initial config files that can be included as part of the data source configurations. I have other patches for different components, but this issue is just to get two data source definitions added to the jbossas/trunk/connector/src/etc/example-config directory, one for a  local-tx-datasource and one for a xa-datasource.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 21:39:56 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Thu, 25 Jun 2009 21:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1667) MBeans
 cannot have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31994.1245980396701.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473842#action_12473842 ] 

Richard Kennard commented on JBMESSAGING-1667:
----------------------------------------------

Fair enough, I will use dots.

Many thanks for spending time discussing and looking into this issue for me.

Regards,

Richard.

> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 22:47:56 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 25 Jun 2009 22:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2143) marshalling of
 facthandle as externalForm
Message-ID: <2548603.1245984476473.JavaMail.jira@cloud.prod.atl2.jboss.com>

marshalling of facthandle as externalForm
-----------------------------------------

                 Key: JBRULES-2143
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2143
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Michael Neale
            Assignee: Michael Neale
             Fix For: 5.1.0.M1


Don't need to unmarshal, but would be nice to marshal fact handles as <fact-handle externalForm=...>

Needed for the advisor/smart forms thing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 22:51:56 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 25 Jun 2009 22:51:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2143) marshalling of
 facthandle as externalForm
In-Reply-To: <2548603.1245984476473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8512767.1245984716468.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Neale closed JBRULES-2143.
----------------------------------

    Resolution: Done


> marshalling of facthandle as externalForm
> -----------------------------------------
>
>                 Key: JBRULES-2143
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2143
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Michael Neale
>            Assignee: Michael Neale
>             Fix For: 5.1.0.M1
>
>
> Don't need to unmarshal, but would be nice to marshal fact handles as <fact-handle externalForm=...>
> Needed for the advisor/smart forms thing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 23:07:56 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 25 Jun 2009 23:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2129) The
 WorkingMemoryEventListener doesn't set the oldObject for objectUpdated
 method.
In-Reply-To: <5650920.1245368156655.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12436024.1245985676940.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Neale reassigned JBRULES-2129:
--------------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)


> The WorkingMemoryEventListener doesn't set the oldObject for objectUpdated method.
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2129
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2129
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.1.0.M1
>            Reporter: John Bebbington
>            Assignee: Michael Neale
>
> The org.drools.event.rule.impl.ObjectEventImpl.java class has a fairly obvious error in it's constructor.
> The line:
>        object = event.getOldObject();
> Needs to be changed to:
>        oldObject = event.getOldObject();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jun 25 23:09:59 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 25 Jun 2009 23:09:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2129) The
 WorkingMemoryEventListener
 doesn't set the oldObject for objectUpdated method.
In-Reply-To: <5650920.1245368156655.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6259606.1245985799351.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Neale closed JBRULES-2129.
----------------------------------

    Fix Version/s: 5.1.0.M1
       Resolution: Done


> The WorkingMemoryEventListener doesn't set the oldObject for objectUpdated method.
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2129
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2129
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.1.0.M1
>            Reporter: John Bebbington
>            Assignee: Michael Neale
>             Fix For: 5.1.0.M1
>
>
> The org.drools.event.rule.impl.ObjectEventImpl.java class has a fairly obvious error in it's constructor.
> The line:
>        object = event.getOldObject();
> Needs to be changed to:
>        oldObject = event.getOldObject();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 01:50:56 2009
From: jira-events at lists.jboss.org (Mladen Turk (JIRA))
Date: Fri, 26 Jun 2009 01:50:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4558) Connection Timeout
 Immediately After ACKing A Request
In-Reply-To: <29886208.1184706647200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25060641.1245995456784.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mladen Turk closed JBAS-4558.
-----------------------------

    Resolution: Out of Date


Cleanup

> Connection Timeout Immediately After ACKing A Request
> -----------------------------------------------------
>
>                 Key: JBAS-4558
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4558
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Mike Millson
>            Assignee: Mladen Turk
>         Attachments: drop5.cap
>
>
> The customer has an application that periodically sends Web service requests to JBoss AS every 20 secs in sets of 4, to check wether the Web Service is up. They find that JBoss AS occasionally drops the request packets when the HTTP connector timeout is set to 20 seconds. When this happens, the packet sequence is very strange. Attached is an example packet sequence viewable using ethereal/WireShark.
> #275: Client sends request >20 seconds after #274 acknowledgment
> #276: Server sends ACK for #275
> #277: Server sends connection timeout FIN/ACK
> #278 Client sends combined ACK for #277 and FIN/ACK
> #279 Server sends ACK for #278
> Packet #275 was more than 20 seconds after the last packet was sent; however, it was received before the server initiated the connection timeout sequence in packets #277-279. It seems to be unaware of the ACK in #276. Almost as if the timeout sequence started, then before the FIN/ACK could be sent, another packet was received and acknowledged. Some sort of timing issue when a request is sent at the same time a connection times out. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 02:52:56 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 26 Jun 2009 02:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JASSIST-79) Editing
 MethodCall produces
 incorrect byte code | java.lang.VerifyError: Illegal target of jump or
 branch | goto points to invalid instruction
In-Reply-To: <25834444.1239876805355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29860397.1245999176724.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JASSIST-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473871#action_12473871 ] 

Shigeru Chiba commented on JASSIST-79:
--------------------------------------

I fixed this problem (it took long time :-0) and the fix is now in the CVS head.  This fix will be included in the upcoming release 3.11.

> Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | goto points to invalid instruction
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-79
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-79
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>         Environment: $ java -version
> java version "1.6.0_07"
> Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
> Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)
>            Reporter: Martin Burger
>            Assignee: Shigeru Chiba
>         Attachments: jinsi-jassist-79.tgz, Parser.instrumented.class, Parser.instrumented.dump, Parser.original.class, Parser.original.dump, Parser.original.jad, Parser.original.java
>
>
> I instrument method calls in a class called org.mozilla.javascript.Parser.
> If I run (or, load) this class, a java.lang.VerifyError will be thrown:
> Exception in thread "main" java.lang.VerifyError: (class: org/mozilla/javascript/Parser, method: statementHelper signature: (Lorg/mozilla/javascript/TokenStream;)Ljava/lang/Object;) Illegal target of jump or branch
> It seems Javassist introduces a defective goto statement at position 3200 in method statementHelper:
> 3200:        goto    -29495
> Obviously, offset -29495 is an invalid opcode address.
> The corresponding Java code (excerpt):
>         switch(tt) {
>         case TokenStream.IF: {
>             skipsemi = true;
>             sourceAdd((char)ts.IF);
>             int lineno = ts.getLineno();
>             Object cond = condition(ts);
>             sourceAdd((char)ts.LC);
>             sourceAdd((char)ts.EOL);
>             Object ifTrue = statement(ts);
>             Object ifFalse = null;
>             if (ts.matchToken(ts.ELSE)) {
>                 sourceAdd((char)ts.RC);
>                 sourceAdd((char)ts.ELSE);
>                 sourceAdd((char)ts.LC);
>                 sourceAdd((char)ts.EOL);
>                 ifFalse = statement(ts);
>             }
>             sourceAdd((char)ts.RC);
>             sourceAdd((char)ts.EOL);
>             pn = nf.createIf(cond, ifTrue, ifFalse, lineno);
>             break;
>         }
>         case TokenStream.SWITCH: {
> I think the break statement is related to this defect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 02:54:56 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 26 Jun 2009 02:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-80) Editing MethodCall
 produces
 incorrect byte code | java.lang.VerifyError: Illegal target of jump or
 branch | invalid instruction
In-Reply-To: <24108261.1239967464758.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5013090.1245999296586.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-80.
----------------------------------

       Resolution: Done
    Fix Version/s: 3.11.0.GA


See JASSIST-79

> Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | invalid instruction
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-80
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-80
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>         Environment: $ java -version
> java version "1.6.0_07"
> Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
> Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode) 
>            Reporter: Martin Burger
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>         Attachments: TokenStream.java, TokenStream_instrumented.class, TokenStream_instrumented.dump, TokenStream_original.class
>
>
> Note: Most likely this issue is related to JASSIST-79.
> I instrument method calls in a class called org.mozilla.javascript.TokenStream.
> If I run (or, load) this class, a java.lang.VerifyError will be thrown:
> Exception in thread "main" java.lang.VerifyError: (class: org/mozilla/javascript/TokenStream, method: getToken$JINSI_4etOXffNDXVw signature: ()I) Illegal target of jump or branch
> It seems Javassist introduces a defective goto statement at position 33217 in method getToken$JINSI_4etOXffNDXVw:
> 33217	goto	465
> The corresponding Java code (excerpt):
>             case '-':
>                 if (matchChar('=')) {
>                     this.op = SUB;
>                     c = ASSIGN;
>                 } else if (matchChar('-')) {
>                     if (0 == (flags & TSF_DIRTYLINE)) {
>                         // treat HTML end-comment after possible whitespace
>                         // after line start as comment-utill-eol
>                         if (matchChar('>')) {
>                             skipLine();
>                             continue retry;
>                         }
>                     }
>                     c = DEC;
>                 } else {
>                     c = SUB;
>                 }
>                 flags |= TSF_DIRTYLINE;
>                 return c;
> I think the continue statement is related to this defect.
> JAD fails to decompile the instrumented class:
> ERROR: invalid instruction at 33217 in the method getToken$JINSI_4etOXffNDXVw. The method will be decompiled incorrectly.
> Javassist's framedump fails, too:
> Exception in thread "main" java.lang.RuntimeException: javassist.bytecode.BadBytecode: Stack is empty[pos = 465]
>         at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:89)
>         at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:60)
>         at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:51)
>         at javassist.tools.framedump.main(framedump.java:45)
> Caused by: javassist.bytecode.BadBytecode: Stack is empty[pos = 465]
>         at javassist.bytecode.analysis.Analyzer.analyzeNextEntry(Analyzer.java:179)
>         at javassist.bytecode.analysis.Analyzer.analyze(Analyzer.java:143)
>         at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:87)
>         ... 3 more
> Caused by: java.lang.IndexOutOfBoundsException: Stack is empty
>         at javassist.bytecode.analysis.Frame.pop(Frame.java:130)
>         at javassist.bytecode.analysis.Executor.simplePop(Executor.java:970)
>         at javassist.bytecode.analysis.Executor.evalStore(Executor.java:869)
>         at javassist.bytecode.analysis.Executor.execute(Executor.java:188)
>         at javassist.bytecode.analysis.Analyzer.analyzeNextEntry(Analyzer.java:177)
>         ... 5 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 02:56:56 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 26 Jun 2009 02:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-79) Editing MethodCall
 produces
 incorrect byte code | java.lang.VerifyError: Illegal target of jump or
 branch | goto points to invalid instruction
In-Reply-To: <25834444.1239876805355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32026912.1245999416463.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-79.
----------------------------------

       Resolution: Done
    Fix Version/s: 3.11.0.GA


> Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | goto points to invalid instruction
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-79
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-79
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>         Environment: $ java -version
> java version "1.6.0_07"
> Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
> Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)
>            Reporter: Martin Burger
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>         Attachments: jinsi-jassist-79.tgz, Parser.instrumented.class, Parser.instrumented.dump, Parser.original.class, Parser.original.dump, Parser.original.jad, Parser.original.java
>
>
> I instrument method calls in a class called org.mozilla.javascript.Parser.
> If I run (or, load) this class, a java.lang.VerifyError will be thrown:
> Exception in thread "main" java.lang.VerifyError: (class: org/mozilla/javascript/Parser, method: statementHelper signature: (Lorg/mozilla/javascript/TokenStream;)Ljava/lang/Object;) Illegal target of jump or branch
> It seems Javassist introduces a defective goto statement at position 3200 in method statementHelper:
> 3200:        goto    -29495
> Obviously, offset -29495 is an invalid opcode address.
> The corresponding Java code (excerpt):
>         switch(tt) {
>         case TokenStream.IF: {
>             skipsemi = true;
>             sourceAdd((char)ts.IF);
>             int lineno = ts.getLineno();
>             Object cond = condition(ts);
>             sourceAdd((char)ts.LC);
>             sourceAdd((char)ts.EOL);
>             Object ifTrue = statement(ts);
>             Object ifFalse = null;
>             if (ts.matchToken(ts.ELSE)) {
>                 sourceAdd((char)ts.RC);
>                 sourceAdd((char)ts.ELSE);
>                 sourceAdd((char)ts.LC);
>                 sourceAdd((char)ts.EOL);
>                 ifFalse = statement(ts);
>             }
>             sourceAdd((char)ts.RC);
>             sourceAdd((char)ts.EOL);
>             pn = nf.createIf(cond, ifTrue, ifFalse, lineno);
>             break;
>         }
>         case TokenStream.SWITCH: {
> I think the break statement is related to this defect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 03:07:56 2009
From: jira-events at lists.jboss.org (Salvatore Di Franca (JIRA))
Date: Fri, 26 Jun 2009 03:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7058) JBOSS: HEAP MEMROY
	USAGE
Message-ID: <26729176.1246000076871.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBOSS: HEAP MEMROY USAGE
------------------------

                 Key: JBAS-7058
                 URL: https://jira.jboss.org/jira/browse/JBAS-7058
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: System service
    Affects Versions: JBossAS-5.1.0.GA
         Environment: OS Ubuntu 8.04 kernel 2.6.24
JVM 1.6_14
CPU: Intel Core 2 duo 3.00 GHZ E8400
            Reporter: Salvatore Di Franca
            Assignee: Dimitris Andreadis


When i start the Jboss application server the  percentage of heap used splashes 99% how you see follows:.

{Heap before GC invocations=142 (full 1):
 PSYoungGen      total 56832K, used 55472K [0xb07d0000, 0xb40b0000, 0xb40b0000)
  eden space 55360K, 100% used [0xb07d0000,0xb3de0000,0xb3de0000)
  from space 1472K, 7% used [0xb3f40000,0xb3f5c000,0xb40b0000)
  to   space 1408K, 0% used [0xb3de0000,0xb3de0000,0xb3f40000)
 PSOldGen        total 466048K, used 198091K [0x940b0000, 0xb07d0000, 0xb07d0000)
  object space 466048K, 42% used [0x940b0000,0xa0222d38,0xb07d0000)
 PSPermGen       total 64384K, used 64371K [0x740b0000, 0x77f90000, 0x940b0000)
  object space 64384K, 99% used [0x740b0000,0x77f8ce08,0x77f90000)
Heap after GC invocations=142 (full 1):
 PSYoungGen      total 56768K, used 144K [0xb07d0000, 0xb40b0000, 0xb40b0000)
  eden space 55360K, 0% used [0xb07d0000,0xb07d0000,0xb3de0000)
  from space 1408K, 10% used [0xb3de0000,0xb3e04000,0xb3f40000)
  to   space 1280K, 0% used [0xb3f70000,0xb3f70000,0xb40b0000)
 PSOldGen        total 466048K, used 198091K [0x940b0000, 0xb07d0000, 0xb07d0000)
  object space 466048K, 42% used [0x940b0000,0xa0222d38,0xb07d0000)
 PSPermGen       total 64384K, used 64371K [0x740b0000, 0x77f90000, 0x940b0000)
  object space 64384K, 99% used [0x740b0000,0x77f8ce08,0x77f90000)
}


I am starting jboss with the following jvm params; -Xms512m -Xmx512m -XX:MaxPermSize=512M -XX:+PrintHeapAtGC



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 03:09:56 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 26 Jun 2009 03:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-85) IllegalAccessError
 when trying to call clone() on a class generated by ProxyFactory
In-Reply-To: <15165406.1245755876804.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21229795.1246000196737.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-85.
----------------------------------

    Fix Version/s: 3.11.0.GA
       Resolution: Done


I applied the patch.  Thanks!

> IllegalAccessError when trying to call clone() on a class generated by ProxyFactory
> -----------------------------------------------------------------------------------
>
>                 Key: JASSIST-85
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-85
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>            Reporter: Tobias Meyer
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>
> Hibernate 3.3 uses javassist (by default) to generate LazyInitializer Objects.
> If a lazily loaded object implements the clone() method, and makes it public, there will be a runtime IllegalAccessError because the javassist proxy object exports the protected definition of Object.clone() instead of the definition in the MethodHandler's Interface.
> The supplied patch makes the ProxyFactory to never reduce the visibility of a public method, even if implemented in a higher interface or the superclass.
> Normally the java compiler would catch such an error, so this is assumed to be save.
> Side effect is of course that a superclass method given to ProxyFactory might not be called as before because a public definition of the MethodHandler (Interface) overloads it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 03:22:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 26 Jun 2009 03:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1857) Track the
 upgrades during EJB3 plugin 1.0.10 release
Message-ID: <11399327.1246000976433.JavaMail.jira@cloud.prod.atl2.jboss.com>

Track the upgrades during EJB3 plugin 1.0.10 release
----------------------------------------------------

                 Key: EJBTHREE-1857
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1857
             Project: EJB 3.0
          Issue Type: Task
          Components: plugin
            Reporter: jaikiran pai
            Assignee: jaikiran pai


This issue is to track any updates to version dependencies during the EJB3 1.0.10 plugin release.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 03:45:56 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 26 Jun 2009 03:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBDEPLOY-201) Wrong deployers
 ordering when multiple inputs specified on many deployers
In-Reply-To: <11921613.1245849596639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19234099.1246002356568.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated JBDEPLOY-201:
------------------------------------

    Comment: was deleted


> Wrong deployers ordering when multiple inputs specified on many deployers
> -------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-201
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-201
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Richard Opalka
>            Assignee: Ales Justin
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 04:03:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 26 Jun 2009 04:03:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1856) NPE if
 "res-type" element is
 missing in ejb-jar.xml for injection of SessionContext
In-Reply-To: <8850904.1245957128139.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18251582.1246003436494.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1856.
------------------------------------

    Resolution: Duplicate Issue


Turns out to be the same issue as this one https://jira.jboss.org/jira/browse/EJBTHREE-1823. Could you please use our EJB3 plugin http://www.jboss.org/ejb3/ejb3plugin.html to upgrade to that version or even our latest version? The released versions of the plugin are available here http://www.jboss.org/ejb3/downloads.html

> NPE if "res-type" element is missing in ejb-jar.xml for injection of SessionContext
> -----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1856
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1856
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>
> I have an ejb-jar.xml for an annotation free EJB. I try to inject a SessionContext.
> With JBoss 5.0, this snippet worked:
> 			<resource-ref>
> 				<res-ref-name>NameDoesNotCare</res-ref-name>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.some.package.SecuredBean</injection-target-class>
> 					<injection-target-name>mySessionContext</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> With JBoss 5.1, this fails with a NullPointerException (EJB is "SecuredBean" in "SecurityEJB.jar"):
> 21:02:02,890 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 21:02:02,890 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/C:/temp/jboss-5.1.0.GA/server/default/tmp/jsr88/Security.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying SecurityEJB.jar: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
> 	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:1210)
> 	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.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:413)
> 	at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.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 sun.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	at sun.reflect.GeneratedMethodAccessor304.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.GeneratedMethodAccessor303.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> 	at sun.rmi.transport.Transport$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
> 	... 68 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
> 	... 69 more
> I found that "<res-type>javax.ejb.SessionContext</res-type>" is missing. I think the deployment should raise a meaningful error message.
> I can provide you with a full sample if required.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 05:08:08 2009
From: jira-events at lists.jboss.org (Bulat Nigmatullin (JIRA))
Date: Fri, 26 Jun 2009 05:08:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Admin Join problem
 -GMS flush by coordinator failed
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15203353.1246007288144.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473892#action_12473892 ] 

Bulat Nigmatullin commented on JGRP-985:
----------------------------------------

I have the same issue with 2.8.0 Beta1. This is the logs of two servers (dont pay attention to log timestamps, there is a small misconception with server datetimes):

Joining server: 

2009.06.26 13:03:17 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:03:24 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:03:31 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:03:38 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:03:45 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:03:52 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:03:59 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:04:06 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:04:13 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:04:20 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying
2009.06.26 13:04:27 join(jabber01.rambler.ru-50481) sent to jabber02.rambler.ru-42629 timed out (after 7000 ms), retrying

Coordinator server:

2009.06.26 13:10:32 jabber02.rambler.ru-42629: GMS flush by coordinator failed
2009.06.26 13:10:47 jabber02.rambler.ru-42629: GMS flush by coordinator failed
2009.06.26 13:11:03 jabber02.rambler.ru-42629: GMS flush by coordinator failed
2009.06.26 13:11:20 jabber02.rambler.ru-42629: GMS flush by coordinator failed
2009.06.26 13:11:35 jabber02.rambler.ru-42629: GMS flush by coordinator failed
2009.06.26 13:11:37 jabber02.rambler.ru-42629: failed to collect all ACKs (expected=5) for view [jabber02.rambler.ru-42629|38] [jabber02.rambler.ru-42629, jabber15.rambler.ru-14938, jabber16.rambler.ru-24876, jabber17.rambler.ru-30400, jabber01.rambler.ru-48589, jabber01.rambler.ru-50481] after 2000ms, missing ACKs from [jabber15.rambler.ru-14938, jabber01.rambler.ru-48589] (received=[jabber17.rambler.ru-30400, jabber16.rambler.ru-24876, jabber02.rambler.ru-42629])
2009.06.26 13:12:58 jabber02.rambler.ru-42629: GMS flush by coordinator failed
2009.06.26 13:13:00 jabber02.rambler.ru-42629: failed to collect all ACKs (expected=5) for view [jabber02.rambler.ru-42629|39] [jabber02.rambler.ru-42629, jabber15.rambler.ru-14938, jabber16.rambler.ru-24876, jabber17.rambler.ru-30400, jabber01.rambler.ru-50481] after 2000ms, missing ACKs from [jabber15.rambler.ru-14938] (received=[jabber17.rambler.ru-30400, jabber16.rambler.ru-24876, jabber02.rambler.ru-42629, jabber01.rambler.ru-50481])

After two minutes from joining server start GMS was OK, but other flushes was broken:

Joining server:

2009.06.26 13:12:08 Flush failed at jabber01.rambler.ru-50481:Sessions by Hostname
2009.06.26 13:12:10 failed to collect all service ACKs (5) for [dst: <null>, src: jabber01.rambler.ru-50481 (4 headers), size=0 bytes] after 2000ms, missing ACKs from [jabber15.rambler.ru-14938] (received=[jabber17.rambler.ru-30400, jabber16.rambler.ru-24876, jabber02.rambler.ru-42629, jabber01.rambler.ru-50481]), local_addr=jabber01.rambler.ru-50481
2009.06.26 13:12:36 Flush failed at jabber01.rambler.ru-50481:Remote Users Existence
2009.06.26 13:12:38 failed to collect all service ACKs (5) for [dst: <null>, src: jabber01.rambler.ru-50481 (4 headers), size=0 bytes] after 2000ms, missing ACKs from [jabber15.rambler.ru-14938] (received=[jabber17.rambler.ru-30400, jabber16.rambler.ru-24876, jabber02.rambler.ru-42629, jabber01.rambler.ru-50481]), local_addr=jabber01.rambler.ru-50481


Member server:

2009.06.26 13:06:34 jabber15.rambler.ru-14938: discarded message from non-member jabber01.rambler.ru-50481, my view is [jabber02.rambler.ru-42629|17] [jabber02.rambler.ru-42629, jabber15.rambler.ru-14938, jabber16.rambler.ru-24876, jabber17.rambler.ru-30400]
2009.06.26 13:06:43 jabber15.rambler.ru-14938: discarded message from non-member jabber01.rambler.ru-50481, my view is [jabber02.rambler.ru-42629|17] [jabber02.rambler.ru-42629, jabber15.rambler.ru-14938, jabber16.rambler.ru-24876, jabber17.rambler.ru-30400]
2009.06.26 13:07:01 jabber15.rambler.ru-14938: discarded message from non-member jabber01.rambler.ru-50481, my view is [jabber02.rambler.ru-42629|17] [jabber02.rambler.ru-42629, jabber15.rambler.ru-14938, jabber16.rambler.ru-24876, jabber17.rambler.ru-30400]
2009.06.26 13:07:03 jabber15.rambler.ru-14938: discarded message from non-member jabber01.rambler.ru-50481, my view is [jabber02.rambler.ru-42629|17] [jabber02.rambler.ru-42629, jabber15.rambler.ru-14938, jabber16.rambler.ru-24876, jabber17.rambler.ru-30400]
2009.06.26 13:07:03 jabber15.rambler.ru-14938: discarded message from non-member jabber01.rambler.ru-50481, my view is [jabber02.rambler.ru-42629|17] [jabber02.rambler.ru-42629, jabber15.rambler.ru-14938, jabber16.rambler.ru-24876, jabber17.rambler.ru-30400]



> Admin  Join problem -GMS flush by coordinator failed
> ----------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 05:30:08 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 05:30:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-984) JGroups can not
 parse IPV6 literals in TCPPING protocol configuration
In-Reply-To: <7188979.1242741125294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1579206.1246008608567.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473896#action_12473896 ] 

Bela Ban commented on JGRP-984:
-------------------------------

I tried this with 2.4 branch and CVS head (2.8) and in both cases, this worked fine for me. Can you paste a stack trace, and your entire config file ?

> JGroups can not parse IPV6 literals in TCPPING protocol configuration
> ---------------------------------------------------------------------
>
>                 Key: JGRP-984
>                 URL: https://jira.jboss.org/jira/browse/JGRP-984
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.6
>            Reporter: Brian Stansberry
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> ON JBPAPP-2013 Dominik Pospisil reports the IPv6 address parsing fix in 2.4.6 doesn't handle TCPPING:
> Both
> <TCPPING initial_hosts="::1[7810],fec0::f101:21a:a0ff:fea0:d745[7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> and
> <TCPPING initial_hosts="[::1][7810],[fec0::f101:21a:a0ff:fea0:d745][7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> fails with:
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "::1"
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "fec0::f101:21a:a0ff:fea0:d745"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 05:38:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 05:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-957) Intermittent
 cluster stability issues
In-Reply-To: <4862356.1239785615454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30018012.1246009136503.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473897#action_12473897 ] 

Bela Ban commented on JGRP-957:
-------------------------------

2.7 is not a supported version, use either 2.6.x or 2.8 and resubmit if the problem still occurs

> Intermittent cluster stability issues
> -------------------------------------
>
>                 Key: JGRP-957
>                 URL: https://jira.jboss.org/jira/browse/JGRP-957
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: jdk 1.5
>            Reporter: a C
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: jgroups-logs.zip
>
>
> We are using jgroups as a notification system between webapps running inside tomcat or weblogic server. In our current test platform all cluster nodes are on the same host, most of them on the same container (tomcat). Some web-applictions may have several connections to the cluster.
> We use UDP multicast on a LAN, the configuration is nearly the default one.
> The system seems to work fine but regularly  we have cluster stability issues. Typically lot of SUSPECT messages are exchanged, a lot of "GMS: address ..."  items are logged on standard output, the number of view accepted events dramatically increases.
> As an example, looking at the number of  viewaccepted (grep -c viewAccepted */logout.log):
> logout.log.2009-03-25:6
> logout.log.2009-03-26:51
> logout.log.2009-03-27:49
> logout.log.2009-03-28:0
> logout.log.2009-03-29:2290
> logout.log.2009-03-30:64
> logout.log.2009-03-31:55
> logout.log.2009-04-01:15
> logout.log.2009-04-02:433
> logout.log.2009-04-03:32
> logout.log.2009-04-04:4
> logout.log.2009-04-05:5
> logout.log.2009-04-06:38
> logout.log.2009-04-07:26
> logout.log.2009-04-08:30
> logout.log.2009-04-09:19
> logout.log.2009-04-10:32
> logout.log.2009-04-11:5
> logout.log.2009-04-12:7
> logout.log.2009-04-13:2236
> logout.log.2009-04-14:56
> We performed several test campaigns sending and receiving messages during a 2 or 3 dyas period and checking for message loss but everything went right. Until the problems appears again. No network issue was detected by our system administrator.
> Another typical problem is that members send NOT_MEMBER messages causing stacks to shutdown (should I say channels to close?). [ Received NOT_MEMBER event from null I'm being shunned; exiting]. The shun option is not set (neither Channel with auto-reconnect option set) and nevertheless in some cases the stack starts up again (CloserThread - reconnecting to group ...)and in other cases not. Please note that when the stack does not start up automatically, it is impossible to connect to the channel manually (we always receive ChannelClosedException)
> Typically
> [sip at bipro tmusadmin]$ grep -c NOT_MEMBER jgroup.log*
> jgroup.log:0
> jgroup.log.2009-03-30:3
> jgroup.log.2009-03-31:0
> jgroup.log.2009-04-01:0
> jgroup.log.2009-04-02:1370
> jgroup.log.2009-04-07:0
> jgroup.log.2009-04-10:0
> jgroup.log.2009-04-11:11
> jgroup.log.2009-04-12:9
> jgroup.log.2009-04-13:587
> jgroup.log.2009-04-14:0
> A suggestion would be greatly appreciated.
> Sory for the size of the logs!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 05:41:08 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 05:41:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-957) Intermittent
 cluster stability issues
In-Reply-To: <4862356.1239785615454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29955804.1246009268166.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473898#action_12473898 ] 

Bela Ban commented on JGRP-957:
-------------------------------

Note that NOT_MEMBER and shunning has been removed from the 2.8 (currently beta2) release, so this issue should not occur anymore.

> Intermittent cluster stability issues
> -------------------------------------
>
>                 Key: JGRP-957
>                 URL: https://jira.jboss.org/jira/browse/JGRP-957
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: jdk 1.5
>            Reporter: a C
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: jgroups-logs.zip
>
>
> We are using jgroups as a notification system between webapps running inside tomcat or weblogic server. In our current test platform all cluster nodes are on the same host, most of them on the same container (tomcat). Some web-applictions may have several connections to the cluster.
> We use UDP multicast on a LAN, the configuration is nearly the default one.
> The system seems to work fine but regularly  we have cluster stability issues. Typically lot of SUSPECT messages are exchanged, a lot of "GMS: address ..."  items are logged on standard output, the number of view accepted events dramatically increases.
> As an example, looking at the number of  viewaccepted (grep -c viewAccepted */logout.log):
> logout.log.2009-03-25:6
> logout.log.2009-03-26:51
> logout.log.2009-03-27:49
> logout.log.2009-03-28:0
> logout.log.2009-03-29:2290
> logout.log.2009-03-30:64
> logout.log.2009-03-31:55
> logout.log.2009-04-01:15
> logout.log.2009-04-02:433
> logout.log.2009-04-03:32
> logout.log.2009-04-04:4
> logout.log.2009-04-05:5
> logout.log.2009-04-06:38
> logout.log.2009-04-07:26
> logout.log.2009-04-08:30
> logout.log.2009-04-09:19
> logout.log.2009-04-10:32
> logout.log.2009-04-11:5
> logout.log.2009-04-12:7
> logout.log.2009-04-13:2236
> logout.log.2009-04-14:56
> We performed several test campaigns sending and receiving messages during a 2 or 3 dyas period and checking for message loss but everything went right. Until the problems appears again. No network issue was detected by our system administrator.
> Another typical problem is that members send NOT_MEMBER messages causing stacks to shutdown (should I say channels to close?). [ Received NOT_MEMBER event from null I'm being shunned; exiting]. The shun option is not set (neither Channel with auto-reconnect option set) and nevertheless in some cases the stack starts up again (CloserThread - reconnecting to group ...)and in other cases not. Please note that when the stack does not start up automatically, it is impossible to connect to the channel manually (we always receive ChannelClosedException)
> Typically
> [sip at bipro tmusadmin]$ grep -c NOT_MEMBER jgroup.log*
> jgroup.log:0
> jgroup.log.2009-03-30:3
> jgroup.log.2009-03-31:0
> jgroup.log.2009-04-01:0
> jgroup.log.2009-04-02:1370
> jgroup.log.2009-04-07:0
> jgroup.log.2009-04-10:0
> jgroup.log.2009-04-11:11
> jgroup.log.2009-04-12:9
> jgroup.log.2009-04-13:587
> jgroup.log.2009-04-14:0
> A suggestion would be greatly appreciated.
> Sory for the size of the logs!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 05:41:08 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 05:41:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-957) Intermittent cluster
 stability issues
In-Reply-To: <4862356.1239785615454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21207894.1246009268341.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban closed JGRP-957.
-------------------------

    Resolution: Out of Date


2.7 is not a supported version

> Intermittent cluster stability issues
> -------------------------------------
>
>                 Key: JGRP-957
>                 URL: https://jira.jboss.org/jira/browse/JGRP-957
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: jdk 1.5
>            Reporter: a C
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: jgroups-logs.zip
>
>
> We are using jgroups as a notification system between webapps running inside tomcat or weblogic server. In our current test platform all cluster nodes are on the same host, most of them on the same container (tomcat). Some web-applictions may have several connections to the cluster.
> We use UDP multicast on a LAN, the configuration is nearly the default one.
> The system seems to work fine but regularly  we have cluster stability issues. Typically lot of SUSPECT messages are exchanged, a lot of "GMS: address ..."  items are logged on standard output, the number of view accepted events dramatically increases.
> As an example, looking at the number of  viewaccepted (grep -c viewAccepted */logout.log):
> logout.log.2009-03-25:6
> logout.log.2009-03-26:51
> logout.log.2009-03-27:49
> logout.log.2009-03-28:0
> logout.log.2009-03-29:2290
> logout.log.2009-03-30:64
> logout.log.2009-03-31:55
> logout.log.2009-04-01:15
> logout.log.2009-04-02:433
> logout.log.2009-04-03:32
> logout.log.2009-04-04:4
> logout.log.2009-04-05:5
> logout.log.2009-04-06:38
> logout.log.2009-04-07:26
> logout.log.2009-04-08:30
> logout.log.2009-04-09:19
> logout.log.2009-04-10:32
> logout.log.2009-04-11:5
> logout.log.2009-04-12:7
> logout.log.2009-04-13:2236
> logout.log.2009-04-14:56
> We performed several test campaigns sending and receiving messages during a 2 or 3 dyas period and checking for message loss but everything went right. Until the problems appears again. No network issue was detected by our system administrator.
> Another typical problem is that members send NOT_MEMBER messages causing stacks to shutdown (should I say channels to close?). [ Received NOT_MEMBER event from null I'm being shunned; exiting]. The shun option is not set (neither Channel with auto-reconnect option set) and nevertheless in some cases the stack starts up again (CloserThread - reconnecting to group ...)and in other cases not. Please note that when the stack does not start up automatically, it is impossible to connect to the channel manually (we always receive ChannelClosedException)
> Typically
> [sip at bipro tmusadmin]$ grep -c NOT_MEMBER jgroup.log*
> jgroup.log:0
> jgroup.log.2009-03-30:3
> jgroup.log.2009-03-31:0
> jgroup.log.2009-04-01:0
> jgroup.log.2009-04-02:1370
> jgroup.log.2009-04-07:0
> jgroup.log.2009-04-10:0
> jgroup.log.2009-04-11:11
> jgroup.log.2009-04-12:9
> jgroup.log.2009-04-13:587
> jgroup.log.2009-04-14:0
> A suggestion would be greatly appreciated.
> Sory for the size of the logs!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 05:58:57 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Fri, 26 Jun 2009 05:58:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1003) deadlock in TP.send
 - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
Message-ID: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>

deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
------------------------------------------------------------------------------------------------

                 Key: JGRP-1003
                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.7
         Environment: Linux (Debian), kernel 2.6.x
            Reporter: Victor N
            Assignee: Bela Ban


I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).

Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.


1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":

"Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
   java.lang.Thread.State: RUNNABLE                                                                                                                                              
        at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
        at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
        at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
        - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
        at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
        at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
        at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
        at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
        at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
        at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
        at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
        at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
        at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
        at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
        at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
        at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
        at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
        at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
        at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
        at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
        at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
        at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
        at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
        at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
        at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
        at java.lang.Thread.run(Thread.java:619)

   Locked ownable synchronizers:                                                                                                                                                 
        - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
        - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
        - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)


2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:

"Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
   java.lang.Thread.State: WAITING (parking)                                                                                                                                     
        at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
        - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
        at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
        at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
        at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
        at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
        at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
        at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
        at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
        at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
        at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
        at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
        at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
        at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
        at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
        at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
        at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
        at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
        at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
        at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
                                                                                                                                                                                 
   Locked ownable synchronizers:                                                                                                                                                 
        - None


(Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).

Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:00:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 06:00:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1003) deadlock in TP.send
 - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26331567.1246010456699.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1003:
---------------------------

    Fix Version/s: 2.8


> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:09:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 06:09:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20546776.1246010997450.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473902#action_12473902 ] 

Bela Ban commented on JGRP-1003:
--------------------------------

Note that we don't support 2.7, I suggest switch to either 2.6.x or 2.8

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:09:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 06:09:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8490635.1246010997024.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473901#action_12473901 ] 

Bela Ban commented on JGRP-1003:
--------------------------------

The question is why does it hang in write(). The reason is that the peer doesn't call Socket.receive(), but we need to find out why.

A few things to try out:
- Use bundling: enable_bundling="true"
- Increase the socket buffer size: recv_buf_size / send_buf_size. The former is more important
- Use send queues in TCP: use_send_queues="true"
- Change the transport's thread pool config, a good one would be
 thread_pool.enabled="true"
         thread_pool.min_threads="2"
         thread_pool.max_threads="8"
         thread_pool.keep_alive_time="5000"
         thread_pool.queue_enabled="true"
         thread_pool.queue_max_size="10000"
         thread_pool.rejection_policy="discard"



> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:28:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Fri, 26 Jun 2009 06:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-97) JBoss Metadata Common
 2.0.0-SNAPSHOT
Message-ID: <21588560.1246012136598.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBoss Metadata Common 2.0.0-SNAPSHOT
------------------------------------

                 Key: JBJCA-97
                 URL: https://jira.jboss.org/jira/browse/JBJCA-97
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha1


metadata project will divide into some sub module, so we use common and rar instead of whole metadata jar
so far we use snapshot until  release version published

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:30:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Fri, 26 Jun 2009 06:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-98) JBoss Metadata Rar
	2.0.0-SNAPSHOT
Message-ID: <23628052.1246012256516.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBoss Metadata Rar 2.0.0-SNAPSHOT
---------------------------------

                 Key: JBJCA-98
                 URL: https://jira.jboss.org/jira/browse/JBJCA-98
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha1


metadata project will divide into some sub module, so we use common and rar instead of whole metadata jar
so far we use snapshot until  release version published

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:30:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Fri, 26 Jun 2009 06:30:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBJCA-68) JBoss Metadata
	1.0.2.Beta1
In-Reply-To: <29947535.1236869745527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28262152.1246012256736.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBJCA-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473904#action_12473904 ] 

Jeff Zhang commented on JBJCA-68:
---------------------------------

metadata project will divide into some sub module, so we use common and rar instead of whole metadata jar 


> JBoss Metadata 1.0.2.Beta1
> --------------------------
>
>                 Key: JBJCA-68
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-68
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha1
>
>
> Standalone + Test

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:32:56 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Fri, 26 Jun 2009 06:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBJCA-68) JBoss Metadata
	1.0.2.Beta1
In-Reply-To: <29947535.1236869745527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13720610.1246012376439.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang closed JBJCA-68.
---------------------------

    Resolution: Done


> JBoss Metadata 1.0.2.Beta1
> --------------------------
>
>                 Key: JBJCA-68
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-68
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha1
>
>
> Standalone + Test

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:39:56 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Fri, 26 Jun 2009 06:39:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3781209.1246012796972.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473905#action_12473905 ] 

Victor N commented on JGRP-1003:
--------------------------------

Yes, Bela,I will try with 2.8 and I am going to use TCP_NIO, this should be more safe.

As I know, there is no way to prevent socket write from hanging in blocking I/O approach in Java, because most of operating system does not allow to set  a socket write timeout. There is SO_TIMEOUT which means socket read timeout, but there is not timeout for writing. So I suppose that in blocking I/O it is not safe to do socket write inside a lock.

I do not think that socket buffer sizes can help. Also, thread pool settings may be different, but if some thread owns an exclusive lock forever, this will not help.

I will look into 2.8 code to see how enable_bundling and use_send_queues changes behavior.

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 06:42:56 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Fri, 26 Jun 2009 06:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10604794.1246012976924.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473906#action_12473906 ] 

Victor N commented on JGRP-1003:
--------------------------------

I can see that 2.8 uses the same code in TP.send:

out_stream_lock.lock();
        try {
            out_stream.reset();
            dos.reset();
            writeMessage(msg, dos, multicast);
            Buffer buf=new Buffer(out_stream.getRawBuffer(), 0, out_stream.size());
            doSend(buf, dest, multicast);
        }
        finally {
            out_stream_lock.unlock();
        }

So socket write is done inside a lock, and the behavior does not depend on enable_bundling and use_send_queues/

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 07:51:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 07:51:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <592074.1246017117060.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473924#action_12473924 ] 

Bela Ban commented on JGRP-1003:
--------------------------------

use_send_queues will *copy* the buffer and add it to a queue, then return immediately and release the lock. A separate thread will then send (and possibly block). This should help.

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 08:27:56 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Fri, 26 Jun 2009 08:27:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15797605.1246019276978.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473931#action_12473931 ] 

Victor N commented on JGRP-1003:
--------------------------------

Thanks, I see this in the code now!
use_send_queues should help.

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 08:42:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 26 Jun 2009 08:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1667) MBeans cannot
 have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19348086.1246020176645.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1667.
-----------------------------------

    Resolution: Rejected


close this as discussed.

> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 08:52:57 2009
From: jira-events at lists.jboss.org (Martin Gekeler (JIRA))
Date: Fri, 26 Jun 2009 08:52:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7059) Compatibility issue
 JBoss-5.1.0.GA -> JBoss-5.0.0.GA
Message-ID: <6442969.1246020777740.JavaMail.jira@cloud.prod.atl2.jboss.com>

Compatibility issue JBoss-5.1.0.GA -> JBoss-5.0.0.GA 
-----------------------------------------------------

                 Key: JBAS-7059
                 URL: https://jira.jboss.org/jira/browse/JBAS-7059
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
         Environment: JBoss-5.1.0.GA, Windows, local PC. 
            Reporter: Martin Gekeler


java.lang.ClassCastException: javax.naming.Reference cannot be cast to com.sdt.pellworm.ejb.Pellworm
	at com.sdt.pellworm.test.junit.TestPellwormEJB.testSayHello(TestPellwormEJB.java:29)
	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 junit.framework.TestCase.runTest(TestCase.java:168)
	at junit.framework.TestCase.runBare(TestCase.java:134)
	at junit.framework.TestResult$1.protect(TestResult.java:110)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.framework.TestResult.run(TestResult.java:113)
	at junit.framework.TestCase.run(TestCase.java:124)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

When i call the test case below from within eclipse I get this exception with JBoss-5.1.0.GA. 
I do not get it with JBoss-5.0.0.GA. 

Here's the code: 

public class TestPellwormEJB extends TestCase {

public void testSayHello() {
      InitialContext  ctx    = null; 
      Pellworm tsBean = null; 

      TestUtils.echoLogHello(this.getClass().getSimpleName(), this.getName()); 
      try {
         ctx    = new InitialContext(TestUtils.createInitialContext());
      } catch (NamingException e) {
         fail(e.getMessage()); 
      }
      try {
         // tsBean = (Pellworm) ctx.lookup("PellwormBean/remote");
         Object object = ctx.lookup("PellwormBean/remote");
         tsBean = (Pellworm) object; 
      } catch (NamingException e) {
         fail(e.getMessage()); 
      }
                  
      try {
         assertEquals("Hallo! Ich bin Pellworm. ", tsBean.sayHello());
      } catch (RemoteException e) {
         fail(e.getMessage()); 
      }
   }
   
}  

I haven't found a compatiblity issue in the release notes about this. 

Cheers, 
-M.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 08:54:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 26 Jun 2009 08:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1668) NPE when
 setting 'messageCounterHistoryDayLimit' prop on JMS Topics
Message-ID: <12342600.1246020896461.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics
-------------------------------------------------------------------

                 Key: JBMESSAGING-1668
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1668
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Configuration and Management
    Affects Versions: 1.4.3.GA, 1.4.0.SP3.CP08
            Reporter: Howard Gao
            Assignee: Howard Gao
             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 08:56:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 26 Jun 2009 08:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1667) MBeans
 cannot have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11217257.1246021016510.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox reopened JBMESSAGING-1667:
----------------------------------



The issue shouldn't be closed.

Like I mentioned in my earlier comment, we should explicit check that destination names do not contain forward slashes, log a warning and reject deployment if so.

> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 09:00:57 2009
From: jira-events at lists.jboss.org (Nicolas Heron (JIRA))
Date: Fri, 26 Jun 2009 09:00:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2141) In a rule flow,
 when the action is in MVEL, it is not possible to import classes
In-Reply-To: <5800231.1245931797780.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18727007.1246021257280.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473935#action_12473935 ] 

Nicolas Heron commented on JBRULES-2141:
----------------------------------------

the error is the same on a drl file in the then part
in mvel syntax, import are not considered

I have to explicitely put all the class name including package

instead of 
--------------
import fr.sopra.impo.ImpotPersonne

//some code

when 
then
    ImpotPersonne a = new ImpotPersonne()
end
-----------
i have to put
---------------
import fr.sopra.impo.ImpotPersonne

//some code

when 
then
    fr.sopra.impo.ImpotPersonne a = new fr.sopra.impo.ImpotPersonne()
end
-------------

> In a rule flow, when the action is in MVEL, it is not possible to import classes
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-2141
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2141
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-eclipse (flow)
>    Affects Versions: FUTURE
>            Reporter: Nicolas Heron
>            Assignee: Mark Proctor
>
> example : 
> -----------
> Long montant = (Long)context.getVariable("surimposition");
> System.out.println ("Surimposition : '" + montant + "'");
>  filter = new org.drools.runtime.ClassObjectFilter (fr.sopra.impot.Impot.class);
> java.util.Collection impots = context.getKnowledgeRuntime().getObjects(filter);
> if (impots.size()==1) {
> 	Impot impot = (Impot)impots.toArray()[0]; 
> 	impot.setMontantRedressement(montant);
> }
> ---------------
> it says  at design time : 
> Process 'ImpotProcess' [fr.sopra.impot.ImpotProcess]: Action node 'Traitement des resultats' [13] has invalid action: was expecting type: java.lang.Object; but found type: null.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 09:07:56 2009
From: jira-events at lists.jboss.org (Bernd Ruecker (JIRA))
Date: Fri, 26 Jun 2009 09:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2144) Drools 5 Plugin
 overwrite Drools 4 RuleFlow & DSL
Message-ID: <2129301.1246021676517.JavaMail.jira@cloud.prod.atl2.jboss.com>

Drools 5 Plugin overwrite Drools 4 RuleFlow & DSL
-------------------------------------------------

                 Key: JBRULES-2144
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2144
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
            Reporter: Bernd Ruecker
            Assignee: Mark Proctor


When using the Drools 5 Eclipse plugin you can select either Drools 4 or Drools 5 for a new project. This indicates, that both should be supported by the pugin.

But when opening a Drools 4 DSL with the editor, it seems to overwrite it with the Drools 5 format.

Same for RuleFlow.

Especially because the selection at the beginning suggets both versions are fully supported by the plugin, this is a bit annoying ;-)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 09:49:03 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 09:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7057) Update Kernel to
	2.0.8.GA
In-Reply-To: <28464517.1245960176528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24302469.1246024143487.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7057:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> Update Kernel to 2.0.8.GA
> -------------------------
>
>                 Key: JBAS-7057
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7057
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 09:49:03 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 09:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7056) Update to JBoss AOP
	2.1.3.GA
In-Reply-To: <4474870.1245959876452.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13966883.1246024143354.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7056:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> Update to JBoss AOP 2.1.3.GA
> ----------------------------
>
>                 Key: JBAS-7056
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7056
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 09:58:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 26 Jun 2009 09:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14903925.1246024736508.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-978:
-------------------------------------

    Attachment: UDP.java


A preliminary implementation of the algorithm to provide version consistent IP addresses.

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>         Attachments: UDP.java
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:07:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 26 Jun 2009 10:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <350291.1246025276508.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473963#action_12473963 ] 

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

Bela

I've attached a preliminary version of the algorithm to check for version consistent addresses in the case of UDP. Some utilities are missing, but this will give you the idea.

The idea is that if any of bind_addr, mcast_addr, diagnostics_addr or bind_interface are non-null, then the user has specified them and these should be used in calculating the complete set of addresses, those specified as well as required defaults.

bind_addr posed a challenge, as it is set based on any value passed for bind_interface. It just introduces more cases which need to be checked. I had to move bind_addr processing from TP.setProperties() to UDP.init() - it was happening too early and can be influenced by values for mcast_addr and diagnostics_addr.

I'm stuck doing EAP stuff at the moment (again) so it may not be until next week before I get a chance to finish this and commit it. Any feedback welcomed..

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>         Attachments: UDP.java
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:16:57 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 26 Jun 2009 10:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics
 uses hard-coded IPv4 multicast address
In-Reply-To: <9123073.1242165766897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25334388.1246025817692.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473967#action_12473967 ] 

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

The other thing I would mention is that it appears that in the existing implementation, because bind_addr is set in TP.setProperties(), it means that by the time UDP.createSockets() is called, bind_addr is never non-null. Which means that the first few lines of code in UDP.creatSockets() (in particular, the one to choose first non-loopback address) never get called. Util.getBindAddress(props) doesn't seem to check for non-loopback addresses...

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>         Attachments: UDP.java
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:24:57 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 26 Jun 2009 10:24:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-84) Add support for
 hasAnnotation(Class) and getAnnotation(Class)
In-Reply-To: <11699216.1244821736498.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29572968.1246026297090.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JASSIST-84:
-----------------------------------

    Attachment:     (was: JASSIST-84.patch)


> Add support for hasAnnotation(Class) and getAnnotation(Class)
> -------------------------------------------------------------
>
>                 Key: JASSIST-84
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-84
>             Project: Javassist
>          Issue Type: Feature Request
>            Reporter: Jesper Pedersen
>            Assignee: Shigeru Chiba
>         Attachments: JASSIST-84.patch
>
>
> It would nice if Javassist had functionality to query 
>  boolean hasAnnotation(Class)
> and retrieve a single annotation 
>  Object getAnnotation(Class)
> for CtClass, CtBehavior and CtField.
> The attached implements this functionality against CVS HEAD.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:24:57 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 26 Jun 2009 10:24:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-84) Add support for
 hasAnnotation(Class) and getAnnotation(Class)
In-Reply-To: <11699216.1244821736498.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26845992.1246026297500.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JASSIST-84:
-----------------------------------

    Attachment: JASSIST-84.patch


> Add support for hasAnnotation(Class) and getAnnotation(Class)
> -------------------------------------------------------------
>
>                 Key: JASSIST-84
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-84
>             Project: Javassist
>          Issue Type: Feature Request
>            Reporter: Jesper Pedersen
>            Assignee: Shigeru Chiba
>         Attachments: JASSIST-84.patch
>
>
> It would nice if Javassist had functionality to query 
>  boolean hasAnnotation(Class)
> and retrieve a single annotation 
>  Object getAnnotation(Class)
> for CtClass, CtBehavior and CtField.
> The attached implements this functionality against CVS HEAD.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:27:10 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 26 Jun 2009 10:27:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <611492.1246026430187.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473970#action_12473970 ] 

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

Emanuel is right. What happens in your case is that the ejb-jar.xml is parsed first. Since it doesn't have a namespace, it's assumed to follow a DTD which means it'll be treated as EJB2. EJB2 don't use annotations, so annotation processing is skipped. And since ejb-jar.xml in your case doesn't describe any beans there is nothing to bind to the JNDI.
If you try describing EJB3 bean in EJB2 ejb-jar.xml you should get an error during deployment.
So, I am going to close it as "won't fix". You can try to convince the EJB3 team on the forums to make the namespace optional. But IMO that's not a good idea.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:28:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 26 Jun 2009 10:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8203529.1246026536537.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBMETA-208.
------------------------------------

    Resolution: Won't Fix


Won't be fixed.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:36:58 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 10:36:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7057) Update Kernel to
	2.0.8.GA
In-Reply-To: <28464517.1245960176528.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26796254.1246027018118.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-7057.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> Update Kernel to 2.0.8.GA
> -------------------------
>
>                 Key: JBAS-7057
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7057
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:36:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 10:36:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7056) Update to JBoss AOP
	2.1.3.GA
In-Reply-To: <4474870.1245959876452.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13265274.1246027017853.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-7056.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
                       (was: JBossAS-5.2.0.Beta1)
       Resolution: Done


> Update to JBoss AOP 2.1.3.GA
> ----------------------------
>
>                 Key: JBAS-7056
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7056
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:36:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 10:36:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7056) Update to JBoss AOP
	2.1.3.GA
In-Reply-To: <4474870.1245959876452.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31168000.1246027017984.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7056:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> Update to JBoss AOP 2.1.3.GA
> ----------------------------
>
>                 Key: JBAS-7056
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7056
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:54:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 10:54:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6889) tests in
 tests-aop-scoped failing with IBM JDK
In-Reply-To: <7099808.1242045886541.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15095722.1246028097420.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6889.
----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


Resolved with JBoss AOP 2.1.3.GA and MC 2.0.8.GA.

> tests in tests-aop-scoped failing with IBM JDK
> ----------------------------------------------
>
>                 Key: JBAS-6889
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6889
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: TEST-org.jboss.test.aop.test.ScopedAnnotatedTestCase-aop-scoped.xml
>
>
> Tests in the tests-aop-scoped target of JBoss AS testsuite are failing.
> The tests are:
> org.jboss.test.aop.test.ScopedAnnotatedTestCase
> org.jboss.test.aop.test.ScopedAttachUnitTestCase
> org.jboss.test.aop.test.ScopedEarWithClassesInWebInfTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseLoadedScopedNoParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseLoadedScopedParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseNotLoadedScopedNoParentDelegationTestCase
> org.jboss.test.aop.test.ScopedExtenderBaseNotLoadedScopedParentDelegationTestCase
> org.jboss.test.aop.test.ScopedUnitTestCase
> org.jboss.test.aop.test.ScopedWovenDependencyTestCase
> The error message is:
> javax.management.RuntimeErrorException
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:182)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: java.lang.ExceptionInInitializerError
> 	at java.lang.J9VMInternals.initialize(J9VMInternals.java:216)
> 	at org.jboss.test.aop.jdk15annotated.ScopedAnnotatedTester.testBinding(ScopedAnnotatedTester.java:50)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.aop.Domain$1.run(Domain.java:124)
> 	at org.jboss.aop.Domain$1.run(Domain.java:121)
> 	at java.security.AccessController.doPrivileged(AccessController.java:197)
> 	at org.jboss.aop.Domain.getDomainName(Domain.java:119)
> 	at org.jboss.test.aop.jdk15annotated.POJO$POJOAdvisor.initialise(POJO$POJOAdvisor.java)
> 	at org.jboss.test.aop.jdk15annotated.POJO$POJOAdvisor.<init>(POJO$POJOAdvisor.java)
> 	at org.jboss.test.aop.jdk15annotated.POJO.<clinit>(POJO.java)
> 	at java.lang.J9VMInternals.initializeImpl(Native Method)
> 	at java.lang.J9VMInternals.initialize(J9VMInternals.java:194)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:54:58 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 10:54:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6888) aoptest.sar unable
 to deploy on IBM JDK - some aop tests failing
In-Reply-To: <5639564.1242043366890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12407759.1246028098359.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6888.
----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


Resolved with JBoss AOP 2.1.3.GA and MC 2.0.8.GA

> aoptest.sar unable to deploy on IBM JDK - some aop tests failing
> ----------------------------------------------------------------
>
>                 Key: JBAS-6888
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6888
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 or 1.6
>            Reporter: Martin Malina
>            Assignee: Flavia Rainone
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: RunIt.java, server.log
>
>
> Several tests in the org.jboss.test.aop.test package fail due to aoptest.sar not being deployed properly.
> The failing tests include:
> org.jboss.test.aop.test.AOPUnitTestCase
> org.jboss.test.aop.test.JMXUnitTestCase
> org.jboss.test.aop.test.ObservableUnitTestCase
> org.jboss.test.aop.test.RemotingUnitTestCase
> org.jboss.test.aop.test.SecurityUnitTestCase
> org.jboss.test.aop.test.TxLockUnitTestCase
> org.jboss.test.aop.test.TxUnitTestCase
> org.jboss.test.aop.test.VersionedObjectUnitTestCase
> This is the junit report:
> Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> org.jboss.deployment.DeploymentException: Failed to deploy: file:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:838)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
> 	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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:168)
> 	at java.security.AccessController.doPrivileged(AccessController.java:279)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
> 	at java.lang.Thread.run(Thread.java:810)
> Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=ObservableTester
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/qa/services/hudson/hudson_workspace/workspace/eap5-as-rhel4-x86-ibm/src/jboss-5.1.0.CR1-src/testsuite/output/lib/aoptest.sar/" is in error due to the following reason(s): java.lang.NullPointerException
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:862)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 10:56:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 10:56:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6925) Tests in
 org.jboss.test.cluster
 failing with IBM JDK 1.5 - servlet jsp not deployed
In-Reply-To: <4280736.1242402226518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7381458.1246028217630.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6925.
----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


Resolved with JBoss AOP 2.1.3.GA and MC 2.0.8.GA

> Tests in org.jboss.test.cluster failing with IBM JDK 1.5 - servlet jsp not deployed
> -----------------------------------------------------------------------------------
>
>                 Key: JBAS-6925
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6925
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: server.log-JBAS-6925, server.log-JBAS-6925-sun
>
>
> Some clustered tests are failing with IBM JDK 1.5.
> This is the list:
> org.jboss.test.cluster.defaultcfg.web.field.test.FieldBasedSessionPassivationTestCase
> org.jboss.test.cluster.defaultcfg.web.field.test.ScopedFieldBasedTestCase
> org.jboss.test.cluster.multicfg.web.field.test.FieldBasedTestCase
> org.jboss.test.cluster.multicfg.web.field.test.UndeployFieldTestCase
> In total this cause 105 failures in the AS testsuite (the test cases are run several times with different clustering configuration).
> The failures all look the same. This is an example from org.jboss.test.cluster.defaultcfg.web.field.test.FieldBasedSessionPassivationTestCase.testSessionPassivationWMaxIdle:
> Get OK with url: http://10.16.93.37:8080/http-field-pass/setSession.jsp responseCode: 500
> junit.framework.AssertionFailedError: Get OK with url: http://10.16.93.37:8080/http-field-pass/setSession.jsp responseCode: 500
> 	at org.jboss.test.cluster.testutil.WebTestBase.makeGet(WebTestBase.java:115)
> 	at org.jboss.test.cluster.defaultcfg.web.test.SessionPassivationTestCase.testSessionPassivationWMaxIdle(SessionPassivationTestCase.java:155)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> In the server log, you can see errors like this:
> 17:14:48,650 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception
> java.lang.NullPointerException
> 	at org.jboss.aop.Domain$1.run(Domain.java:124)
> 	at org.jboss.aop.Domain$1.run(Domain.java:121)
> 	at java.security.AccessController.doPrivileged(AccessController.java:197)
> 	at org.jboss.aop.Domain.getDomainName(Domain.java:119)
> 	at org.jboss.test.cluster.web.aop.Person$PersonAdvisor.initialise(Person$PersonAdvisor.java)
> 	at org.jboss.test.cluster.web.aop.Person$PersonAdvisor.<init>(Person$PersonAdvisor.java)
> 	at org.jboss.test.cluster.web.aop.Person.<clinit>(Person.java)
> 	at java.lang.J9VMInternals.initializeImpl(Native Method)
> 	at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
> 	at org.apache.jsp.setSession_jsp._jspService(setSession_jsp.java:65)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94)
> 	at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:810)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 11:31:56 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 26 Jun 2009 11:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-84) Add support for
 hasAnnotation(Class) and getAnnotation(Class)
In-Reply-To: <11699216.1244821736498.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16096190.1246030316581.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-84.
----------------------------------

    Fix Version/s: 3.11.0.GA
       Resolution: Done


I applied the patch.

> Add support for hasAnnotation(Class) and getAnnotation(Class)
> -------------------------------------------------------------
>
>                 Key: JASSIST-84
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-84
>             Project: Javassist
>          Issue Type: Feature Request
>            Reporter: Jesper Pedersen
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>         Attachments: JASSIST-84.patch
>
>
> It would nice if Javassist had functionality to query 
>  boolean hasAnnotation(Class)
> and retrieve a single annotation 
>  Object getAnnotation(Class)
> for CtClass, CtBehavior and CtField.
> The attached implements this functionality against CVS HEAD.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 11:39:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 26 Jun 2009 11:39:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7651458.1246030797461.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473986#action_12473986 ] 

Bela Ban commented on JGRP-1003:
--------------------------------

Let me know if this fixes the issue, so I can close it. I plan on rewriting a TCP transport once we're on JDK 1.7 anyway, to run on NIO, so I don't want to make too many changes to TCP as it stands for now

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 12:10:57 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 26 Jun 2009 12:10:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-549) ConnectionTable:
 spurious Connection instances on concurrent connects
In-Reply-To: <10580511.1183710592881.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6262892.1246032657114.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473989#action_12473989 ] 

Richard Achmatowicz commented on JGRP-549:
------------------------------------------

Looks as though the unit test ConnectionTableTest.testConcurrentConnect() which appears in HEAD:/tests/junit-functional was not pulled back to 2.4.

I'm adding the test to Branch_2_4 version of ConnectionTableTest.
It had to be adjusted slightly as the interface of CyclicBarrier changed from EDU.oswego.cs.dl.util.concurrent to java.util.concurrent. 

> ConnectionTable: spurious Connection instances on concurrent connects
> ---------------------------------------------------------------------
>
>                 Key: JGRP-549
>                 URL: https://jira.jboss.org/jira/browse/JGRP-549
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6
>
>
> If we have members A and B, and they don't yet have connections to each other, and start sending messages to each other at the exact same time, then we run into the following scenario:
> - A attempts to connect to B (new Socket())
> - B attempts to connect to A
> - A accepts B's connection and adds an entry for B into its table
> - B adds an entry for A into its table
> - B gets the accept() from A, but doesn't add the new Connection into its table because there is already a Connection. This leads to a spurious Connection object, which will only be closed and garbage collected once A or B leaves the cluster
> - We used to close Connections which were already in the table, but this lead to ping-pong effects where concurrent initial senders always closed each others connections
> - Even worse: a new Socket() always creates a new Connection object and places it into the table, *regardless* of whether a Connection for a given destination already exists or not !
> GOAL:
> #1 Have only 1 TCP connection between any 2 members
> #2 Establish a handshaking mechanism, to avoid spurious connections
> SOLUTION:
> - When A establishes a connection to B, A needs to get agreement from B first (and vice versa)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 13:10:56 2009
From: jira-events at lists.jboss.org (Calvin Lin (JIRA))
Date: Fri, 26 Jun 2009 13:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7037) JBossAS 5.x fails to
 use EJB's
 security domain in jboss.xml when the call is from web container
In-Reply-To: <2821553.1245299576703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30788021.1246036256665.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Calvin Lin updated JBAS-7037:
-----------------------------

    Workaround Description: 
Our workaround for standalone JBoss AS is to add "CLIENT_LOGIN_MODULE" application-policy in login-config.xml and use that for EJB container authentication.
For clustering environment, the workaround is to add "BYPASSED-SECURITY" application-policy in login-config.xml to handle the EJB container authentication.

  was:Our workaround is to add "CLIENT_LOGIN_MODULE" application-policy in login-config.xml and use that for EJB container authentication.



> JBossAS 5.x fails to use EJB's security domain in jboss.xml when the call is from web container
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7037
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: Problem found on Windows platform
>            Reporter: Calvin Lin
>            Assignee: Stefan Guilhen
>             Fix For: JBossAS-5.0.2.GA
>
>         Attachments: ConfigFiles-lib.zip, JBAS-jira-authenBug.zip
>
>
> A degredation from JBoss 4.0.x and 4.2.x to JBoss 5.0.1.GA and JBoss 5.1.0.GA.
> We noticed that the JAAS login in EJB container always picks up the Web app's security domain when the client login is originated from a web application client.  The security domain specified in EJB container's jboss.xml is always ignored in this situation.
> The detailed problem description is posted on JBoss forum:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156863

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 13:21:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 26 Jun 2009 13:21:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1669) data
 directorires are
 located under ./bin when running on the application server.
Message-ID: <8252217.1246036917141.JavaMail.jira@cloud.prod.atl2.jboss.com>

data directorires are located under ./bin when running on the application server.
---------------------------------------------------------------------------------

                 Key: JBMESSAGING-1669
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1669
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta3
            Reporter: Clebert Suconic
            Assignee: Clebert Suconic
             Fix For: 2.0.0


When running JBossMessaging 2 inside JBoss AS, the data directory, paging and large-message-dir are located under ./bin

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 13:21:57 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 26 Jun 2009 13:21:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1669) data
 directorires are
 located under ./bin when running on the application server.
In-Reply-To: <8252217.1246036917141.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20267026.1246036917577.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1669.
----------------------------------------

    Resolution: Done


> data directorires are located under ./bin when running on the application server.
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1669
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1669
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> When running JBossMessaging 2 inside JBoss AS, the data directory, paging and large-message-dir are located under ./bin

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 14:46:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Fri, 26 Jun 2009 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1858) NPE if in
 resource-env-ref no injection target is specified
Message-ID: <15528450.1246042016731.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE if in resource-env-ref no injection target is specified
-----------------------------------------------------------

                 Key: EJBTHREE-1858
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1858
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: 1.1.7
            Reporter: Wolfgang Knauf
         Attachments: ResourceEnvRefNPE.jar

If an ENC entry for java:/comp/EJBContext is declared and NO injection target is specified, this results in a NPE.

			<resource-env-ref>
				<resource-env-ref-name>EnvNameOfSessionContext</resource-env-ref-name>
 				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
				<mapped-name>java:comp/EJBContext</mapped-name>
			</resource-env-ref>

The exception is:
...
Caused by: java.lang.NullPointerException
	at org.jboss.injection.InjectionUtil.createInjectors(InjectionUtil.java:105)
	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:227)
	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:343)
	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:597)
	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:434)
	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:543)
	... 69 more

Looking at the code in ResourceHandler.loadXmlResourceEnvRefs, this is the only place where the check "if(envRef.getInjectionTargets() != null)" is missing ;-).

I will attach a sample.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 14:46:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Fri, 26 Jun 2009 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1858) NPE if in
 resource-env-ref no injection target is specified
In-Reply-To: <15528450.1246042016731.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18657196.1246042016926.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolfgang Knauf updated EJBTHREE-1858:
-------------------------------------

    Attachment: ResourceEnvRefNPE.jar


Full sampe, including code. Deployment to JBoss 5.1.0GA with updated EJB-plugin 1.1.7 will fail.

> NPE if in resource-env-ref no injection target is specified
> -----------------------------------------------------------
>
>                 Key: EJBTHREE-1858
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1858
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>         Attachments: ResourceEnvRefNPE.jar
>
>
> If an ENC entry for java:/comp/EJBContext is declared and NO injection target is specified, this results in a NPE.
> 			<resource-env-ref>
> 				<resource-env-ref-name>EnvNameOfSessionContext</resource-env-ref-name>
>  				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 			</resource-env-ref>
> The exception is:
> ...
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.InjectionUtil.createInjectors(InjectionUtil.java:105)
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:227)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:343)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:597)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:434)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:543)
> 	... 69 more
> Looking at the code in ResourceHandler.loadXmlResourceEnvRefs, this is the only place where the check "if(envRef.getInjectionTargets() != null)" is missing ;-).
> I will attach a sample.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 14:53:58 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Fri, 26 Jun 2009 14:53:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1856) NPE if
 "res-type" element
 is missing in ejb-jar.xml for injection of SessionContext
In-Reply-To: <8850904.1245957128139.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30816898.1246042438371.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474022#action_12474022 ] 

Wolfgang Knauf commented on EJBTHREE-1856:
------------------------------------------

Thanks, with the new plugin it works. I should have searched for the error message before filing a JIRA.

My initial sample was probably not valid, I should have used a "resource-env-ref" element (which is for injection of "anything else") instead of "res-ref".

> NPE if "res-type" element is missing in ejb-jar.xml for injection of SessionContext
> -----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1856
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1856
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>
> I have an ejb-jar.xml for an annotation free EJB. I try to inject a SessionContext.
> With JBoss 5.0, this snippet worked:
> 			<resource-ref>
> 				<res-ref-name>NameDoesNotCare</res-ref-name>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.some.package.SecuredBean</injection-target-class>
> 					<injection-target-name>mySessionContext</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> With JBoss 5.1, this fails with a NullPointerException (EJB is "SecuredBean" in "SecurityEJB.jar"):
> 21:02:02,890 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 21:02:02,890 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/C:/temp/jboss-5.1.0.GA/server/default/tmp/jsr88/Security.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying SecurityEJB.jar: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
> 	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:1210)
> 	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.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:413)
> 	at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.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 sun.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
> 	at sun.reflect.GeneratedMethodAccessor304.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
> 	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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.GeneratedMethodAccessor303.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> 	at sun.rmi.transport.Transport$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: Exception while processing container metadata for EJB: SecuredBean in unit: SecurityEJB.jar
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
> 	... 68 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
> 	... 69 more
> I found that "<res-type>javax.ejb.SessionContext</res-type>" is missing. I think the deployment should raise a meaningful error message.
> I can provide you with a full sample if required.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 15:18:56 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Fri, 26 Jun 2009 15:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7034) Outdated/missing
 schema files on website
In-Reply-To: <15960137.1245267836412.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5042292.1246043936542.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolfgang Knauf updated JBAS-7034:
---------------------------------

    Description: 
Some xsd files are missing or are outdated (even with validation errors) at http://www.jboss.org/j2ee/schema/

Please update from trunk ( http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/ ):

jboss-ds_5_0.xsd (missing, see also https://jira.jboss.org/jira/browse/JBMETA-210 )
jboss-web_5_1.xsd (missing, see also https://jira.jboss.org/jira/browse/JBMETA-210 )
jboss-client_5_1.xsd (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-210 )
jboss-ra_1_0.xsd  (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-210 )
jboss_common_5_1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.1.xsd (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.0.xsd (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-185 )


bean-deployer_1_0.xsd (missing)
bean-deployer_2_0.xsd (missing)
jboss-beans-common_2_0.xsd (missing)
policy_1_0.xsd (missing)
Note: they do not validate, too (invalid schema locations, and a (maybe false) validation error, see https://jira.jboss.org/jira/browse/JBMICROCONT-446 ), but they should be available on the website anyway.

  was:
Some xsd files are missing or are outdated at http://www.jboss.org/j2ee/schema/

Please update from trunk (http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/):

jboss-ds_5_0.xsd (missing)
jboss-web_5_1.xsd (missing)
jboss_common_5_1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
jboss_5.0.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-185 )
(some still do not validate because of invalid schema locations, so they must be updated again if https://jira.jboss.org/jira/browse/JBMETA-210 is fixed)

bean-deployer_1_0.xsd (missing)
bean-deployer_2_0.xsd (missing)
jboss-beans-common_2_0.xsd (missing)
policy_1_0.xsd (missing)
Note: they do not validate, too (invalid schema locations, and a (maybe false) validation error, see https://jira.jboss.org/jira/browse/JBMICROCONT-446 ), but they should be available on the website anyway.



> Outdated/missing schema files on website
> ----------------------------------------
>
>                 Key: JBAS-7034
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7034
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Wolfgang Knauf
>
> Some xsd files are missing or are outdated (even with validation errors) at http://www.jboss.org/j2ee/schema/
> Please update from trunk ( http://fisheye.jboss.org/browse/JBossAS/projects/metadata/trunk/src/main/resources/schema/ ):
> jboss-ds_5_0.xsd (missing, see also https://jira.jboss.org/jira/browse/JBMETA-210 )
> jboss-web_5_1.xsd (missing, see also https://jira.jboss.org/jira/browse/JBMETA-210 )
> jboss-client_5_1.xsd (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-210 )
> jboss-ra_1_0.xsd  (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-210 )
> jboss_common_5_1.xsd (current file does not validate with eclipse, fixed, see https://jira.jboss.org/jira/browse/JBMETA-200 )
> jboss_5.1.xsd (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-200 )
> jboss_5.0.xsd (current file does not validate with eclipse, fixed by https://jira.jboss.org/jira/browse/JBMETA-185 )
> bean-deployer_1_0.xsd (missing)
> bean-deployer_2_0.xsd (missing)
> jboss-beans-common_2_0.xsd (missing)
> policy_1_0.xsd (missing)
> Note: they do not validate, too (invalid schema locations, and a (maybe false) validation error, see https://jira.jboss.org/jira/browse/JBMICROCONT-446 ), but they should be available on the website anyway.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 15:35:56 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 26 Jun 2009 15:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-549) ConnectionTable:
 spurious Connection instances on concurrent connects
In-Reply-To: <10580511.1183710592881.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18585119.1246044956425.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474026#action_12474026 ] 

Richard Achmatowicz commented on JGRP-549:
------------------------------------------

Done.

> ConnectionTable: spurious Connection instances on concurrent connects
> ---------------------------------------------------------------------
>
>                 Key: JGRP-549
>                 URL: https://jira.jboss.org/jira/browse/JGRP-549
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6
>
>
> If we have members A and B, and they don't yet have connections to each other, and start sending messages to each other at the exact same time, then we run into the following scenario:
> - A attempts to connect to B (new Socket())
> - B attempts to connect to A
> - A accepts B's connection and adds an entry for B into its table
> - B adds an entry for A into its table
> - B gets the accept() from A, but doesn't add the new Connection into its table because there is already a Connection. This leads to a spurious Connection object, which will only be closed and garbage collected once A or B leaves the cluster
> - We used to close Connections which were already in the table, but this lead to ping-pong effects where concurrent initial senders always closed each others connections
> - Even worse: a new Socket() always creates a new Connection object and places it into the table, *regardless* of whether a Connection for a given destination already exists or not !
> GOAL:
> #1 Have only 1 TCP connection between any 2 members
> #2 Establish a handshaking mechanism, to avoid spurious connections
> SOLUTION:
> - When A establishes a connection to B, A needs to get agreement from B first (and vice versa)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 15:57:07 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Fri, 26 Jun 2009 15:57:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <16571178.1246046227969.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7032:
---------------------------------

    Priority: Blocker  (was: Major)


If this is due to a conflict between the Embedded Console RichFaces jars and those of a users application, as described in the recent forum post, then that is a blocker

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 16:33:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 16:33:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6962)
 org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
In-Reply-To: <994948.1242838745393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27900180.1246048437843.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6962:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
> ----------------------------------------------------------------------
>
>                 Key: JBAS-6962
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6962
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: TEST-org.jboss.test.cmp2.commerce.CompleteUnitTestCase.xml
>
>
> With IBM JDK 1.6 the test testJBossQL fails with this message:
> Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> junit.framework.AssertionFailedError: Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> 	at org.jboss.test.cmp2.commerce.QueryTest.testJBossQL(QueryTest.java:169)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)
> It's strange that with IBM 1.6 the failure does not happen in that test, but in different - testEJBQL:
> expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> junit.framework.ComparisonFailure: expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> 	at org.jboss.test.cmp2.commerce.QueryTest.testEJBQL(QueryTest.java:329)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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:193)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Fri Jun 26 16:33:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 16:33:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6934) Tests in
 org.jboss.test.cluster failing with IBM JDK 1.5 - Failed to start
 cluster/http/jboss-web-test-service.xml
In-Reply-To: <23484241.1242648377491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6549361.1246048437525.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6934:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> Tests in org.jboss.test.cluster failing with IBM JDK 1.5 - Failed to start cluster/http/jboss-web-test-service.xml
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6934
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6934
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Some clustered tests are failing with this error message:
> Failed to start cluster/http/jboss-web-test-service.xml
> org.jboss.cache.pojo.PojoCacheException: Failed to start cluster/http/jboss-web-test-service.xml
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.<init>(PojoCacheImpl.java:63)
> 	at org.jboss.cache.pojo.PojoCacheFactory.createCache(PojoCacheFactory.java:42)
> 	at org.jboss.test.cluster.testutil.SessionTestUtil.getConfiguration(SessionTestUtil.java:147)
> 	at org.jboss.test.cluster.testutil.SessionTestUtil.createCache(SessionTestUtil.java:136)
> 	at org.jboss.test.cluster.testutil.CacheConfigTestSetup.setUp(CacheConfigTestSetup.java:84)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: org.jboss.cache.config.ConfigurationException: Unable to build interceptor chain
> 	at org.jboss.cache.factories.InterceptorChainFactory.construct(InterceptorChainFactory.java:229)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:318)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.DefaultCacheFactory.bootstrap(DefaultCacheFactory.java:155)
> 	at org.jboss.cache.DefaultCacheFactory.createAndWire(DefaultCacheFactory.java:141)
> 	at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:120)
> 	at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:93)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.<init>(PojoCacheImpl.java:58)
> Caused by: java.lang.TypeNotPresentException: Type net.jcip.annotations.ThreadSafe not present
> 	at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:38)
> 	at com.ibm.oti.reflect.AnnotationHelper.getDeclaredAnnotations(AnnotationHelper.java:50)
> 	at java.lang.Class.getDeclaredAnnotations(Class.java:1620)
> 	at java.lang.Class.getAnnotations(Class.java:1581)
> 	at java.lang.Class.getAnnotation(Class.java:1561)
> 	at java.lang.Class.isAnnotationPresent(Class.java:1648)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:252)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.InterceptorChainFactory.createInterceptor(InterceptorChainFactory.java:60)
> 	at org.jboss.cache.factories.InterceptorChainFactory.buildInterceptorChain(InterceptorChainFactory.java:75)
> 	at org.jboss.cache.factories.InterceptorChainFactory.construct(InterceptorChainFactory.java:225)
> Caused by: java.lang.ClassNotFoundException: net.jcip.annotations.ThreadSafe
> 	at java.lang.Class.forName(Class.java:163)
> 	at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:33)
> This is the list of the tests failing because of this: 
> org.jboss.test.cluster.defaultcfg.simpleweb.test.AttributeBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.BuddyReplicationFailoverUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.BuddyReplicationToPassivatedSessionUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.ClusteredSessionNotificationPolicyTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.FieldBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.JBossCacheManagerConfigurationUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.ReplicationToPassivatedSessionUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionCountUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionExpirationUnitTestCase
> In total it causes 29 failures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 16:33:58 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 16:33:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6968)
 org.jboss.test.spring.test.SpringClusterTestCase failing with IBM JDK 1.5
In-Reply-To: <32698421.1243001398195.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15115907.1246048438084.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6968:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> org.jboss.test.spring.test.SpringClusterTestCase failing with IBM JDK 1.5
> -------------------------------------------------------------------------
>
>                 Key: JBAS-6968
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6968
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: spring-server.log
>
>
> org.jboss.test.spring.test.SpringClusterTestCase is failing with this message:
> testStandalone	Failure	N/A
> junit.framework.AssertionFailedError
> 	at org.jboss.test.spring.test.SpringClusterTestCase.testStandalone(SpringClusterTestCase.java:43)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> In the server log you can see:
> ...
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/lib/spring-cluster-pojos.jar/" is in error due to the following reason(s): java.lang.ClassNotFoundException: net.jcip.annotations.ThreadSafe
> ...
> Which shows that it is again the same problem with net.jcip.annotations.ThreadSafe missing in IBM JDK as discussed here JBAS-6934 and JBAS-6428.
> Solution: Ensure that jcip-annotations.jar gets copied to server/springdeployer/lib/ when the config is created.
> A. Add jcip-annotations.jar to server/default/lib (it is 2.6 KB) - springdeployer is created out of default
> B. Change testsuite/build.xml to make ant copy jcip-annotations.jar from server/all/lib/ to server/springdeployer/lib/ - don't know how to do that easily
> A. seems easier to do.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 16:33:58 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 26 Jun 2009 16:33:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6967)
 org.jboss.test.security.test.HttpsUnitTestCase failing with IBM JDK
In-Reply-To: <27953188.1242999477645.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23041034.1246048438298.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6967:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> org.jboss.test.security.test.HttpsUnitTestCase failing with IBM JDK
> -------------------------------------------------------------------
>
>                 Key: JBAS-6967
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6967
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: TEST-org.jboss.test.security.test.HttpsUnitTestCase-tests-security-basic-unit.xml
>
>
> When running the AS testsuite, this test case shows an error:
> org.jboss.test.security.test.HttpsUnitTestCase
> The error message is:
> unknown	Error	N/A
> java.lang.NullPointerException
> 	at java.security.Security.insertProviderAt(Security.java:357)
> 	at java.security.Security.addProvider(Security.java:406)
> 	at org.jboss.test.security.test.HttpsUnitTestCase$1.setUp(HttpsUnitTestCase.java:171)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> When you look in the source code, this is the line where it fails:
> Security.addProvider(SecurityProviderUtil.getJSSEProvider());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 16:35:56 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 26 Jun 2009 16:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1839) Implement
 POJO-based, @ManagedObject Session Metrics
In-Reply-To: <32587729.1243384676916.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8898275.1246048556984.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1839.
-------------------------------------------

    Resolution: Done


> Implement POJO-based, @ManagedObject Session Metrics
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1839
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1839
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: metrics-deployer
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.8
>
>         Attachments: metrics.patch
>
>
> Defined by JBAS-6624.
> Consoles need Statistics accessible via ProfileService and jboss-management @ManagedObjects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 16:35:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 26 Jun 2009 16:35:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1831) Clean up
	dependency chains
In-Reply-To: <13433231.1242136368008.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25088041.1246048557441.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated EJBTHREE-1831:
------------------------------------------

    Fix Version/s: 1.1.9
                       (was: 1.1.8)


> Clean up dependency chains
> --------------------------
>
>                 Key: EJBTHREE-1831
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1831
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: as-int, ejb3
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.9
>
>
> The true order should be:
> jboss-ejb3 > as-int > AS
> jboss-ejb3 > Plugin
> Whereas now as-int goes into Plugin.  Also endpoint-deployer should be included in as-int and Plugin, and not explicitly declared by AS itself.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 16:35:57 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 26 Jun 2009 16:35:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1814)
 NoPassivationCache does not obey maxSize
In-Reply-To: <17499438.1240909569920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19162544.1246048557672.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated EJBTHREE-1814:
------------------------------------------

    Fix Version/s: 1.1.9
                       (was: 1.1.8)


> NoPassivationCache does not obey maxSize
> ----------------------------------------
>
>                 Key: EJBTHREE-1814
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1814
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: cache
>            Reporter: Carlo de Wolf
>             Fix For: 1.1.9
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 17:03:07 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 26 Jun 2009 17:03:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1858) NPE if in
 resource-env-ref no injection target is specified
In-Reply-To: <15528450.1246042016731.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <782835.1246050187841.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1858:
--------------------------------------

    Assignee: jaikiran pai


> NPE if in resource-env-ref no injection target is specified
> -----------------------------------------------------------
>
>                 Key: EJBTHREE-1858
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1858
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>         Attachments: ResourceEnvRefNPE.jar
>
>
> If an ENC entry for java:/comp/EJBContext is declared and NO injection target is specified, this results in a NPE.
> 			<resource-env-ref>
> 				<resource-env-ref-name>EnvNameOfSessionContext</resource-env-ref-name>
>  				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 			</resource-env-ref>
> The exception is:
> ...
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.InjectionUtil.createInjectors(InjectionUtil.java:105)
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:227)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:343)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:597)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:434)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:543)
> 	... 69 more
> Looking at the code in ResourceHandler.loadXmlResourceEnvRefs, this is the only place where the check "if(envRef.getInjectionTargets() != null)" is missing ;-).
> I will attach a sample.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 17:03:08 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Fri, 26 Jun 2009 17:03:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20326685.1246050188122.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7051:
---------------------------------

    Assignee: Jason T. Greene  (was: Scott M Stark)


How come the queue-example-service.xml is even able to be deployed...

I thought only JBossMessaging was deployed in JBAS5.0

<?xml version="1.0" encoding="UTF-8"?>
<server>
   <mbean code="org.jboss.mq.server.jmx.Queue"
      name="jboss.mq.destination:service=Queue,name=tutorial">
      <attribute name="JNDIName">queue/tutorial/example</attribute>
      <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
   </mbean>

   <mbean code="org.jboss.mq.server.jmx.Queue"
      name="jboss.mq.destination:service=Queue,name=defaultedtutorial">
      <attribute name="JNDIName">queue/tutorial/defaultedexample</attribute>
      <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
   </mbean>
</server>



> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         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.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         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.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.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         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.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 17:04:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 26 Jun 2009 17:04:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5328584.1246050296940.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474031#action_12474031 ] 

Ian Springer commented on JBAS-7051:
------------------------------------

Note, the file to look at inside the attached ejb-jar is META-INF/queue-example-service.xml.


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Jason T. Greene
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         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.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         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.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.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         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.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 17:14:08 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 26 Jun 2009 17:14:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <24940004.1246050848049.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474032#action_12474032 ] 

Ian Springer commented on JBAS-7032:
------------------------------------

I started a post on this issue in the JBossAS5 Users forum:

  http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157695


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 18:09:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 26 Jun 2009 18:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-514) Improve sar
 generation for varia module
In-Reply-To: <10543048.1235752039200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22163670.1246054196427.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474041#action_12474041 ] 

Paul Gier commented on JBBUILD-514:
-----------------------------------

Replaced the extra Ant file with using the assembly plugin.  Due to MJBOSSPACK-25 we have to wait until the next release of the jboss packaging plugin before the assembly plugin can create .sar artifacts instead of -sar.jar.

> Improve sar generation for varia module
> ---------------------------------------
>
>                 Key: JBBUILD-514
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-514
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Ant is currently used to generate the .sar files in the varia module.  Possibly the jboss-packaging maven plugin could be used to generate these files.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 18:11:56 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 26 Jun 2009 18:11:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-514) Improve sar
 generation for varia module
In-Reply-To: <10543048.1235752039200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27912347.1246054316654.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier closed JBBUILD-514.
-----------------------------

    Resolution: Done


> Improve sar generation for varia module
> ---------------------------------------
>
>                 Key: JBBUILD-514
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-514
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Ant is currently used to generate the .sar files in the varia module.  Possibly the jboss-packaging maven plugin could be used to generate these files.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 18:23:56 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Fri, 26 Jun 2009 18:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6918) "trackByTxn" always
 gets
 displayed as "false" in the output of the "listStatistics" operation for
 Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20450662.1246055036692.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-6918:
---------------------------------

    Priority: Minor  (was: Major)


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 19:38:56 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Fri, 26 Jun 2009 19:38:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <10982794.1246059536707.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474050#action_12474050 ] 

John Ament commented on JBAS-7032:
----------------------------------

Ian - your comments in the thread indicate that I'm doing that stuff that I haven't tried yet.  As of yet, I haven't changed the classloading configuration yet.  

Is the implication that I either downgrade my richfaces or upgrade the admin-console richfaces, and it'll all go away?

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 22:22:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 26 Jun 2009 22:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1668) NPE when
 setting 'messageCounterHistoryDayLimit' prop on JMS Topics
In-Reply-To: <12342600.1246020896461.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30012374.1246069376761.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1668.
-----------------------------------

    Resolution: Done


done

> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics
> -------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1668
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1668
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.3.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jun 26 22:24:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 26 Jun 2009 22:24:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6783) NPE when setting
 'messageCounterHistoryDayLimit' prop on JMS Topics
In-Reply-To: <14608979.1239740062696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17418575.1246069496575.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao resolved JBAS-6783.
------------------------------

    Resolution: Done


fixed

> NPE when setting 'messageCounterHistoryDayLimit' prop on JMS Topics
> -------------------------------------------------------------------
>
>                 Key: JBAS-6783
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6783
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging)
>    Affects Versions: JBossAS-5.1.0.CR1
>            Reporter: Charles Crouch
>            Assignee: Howard Gao
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Setting the "MessageCounterHistoryDayLimit" in a topic deployment descriptor triggers an NPE:
> <attribute name="MessageCounterHistoryDayLimit">10</attribute>
> Caused by: java.lang.NullPointerException
> 	at org.jboss.jms.server.destination.ManagedTopic.getMessageCounters(ManagedTopic.java:159)
> 	at org.jboss.jms.server.destination.ManagedTopic.setMessageCounterHistoryDayLimit(ManagedTopic.java:191)
> Also See https://jira.jboss.org/jira/browse/JBAS-6721?focusedCommentId=12460246#action_12460246 .
> The problem is that the property is only expected to be set at runtime, AFTER the topic has started:
>  Collection queues = serverPeer.getPostOfficeInstance().getQueuesForCondition(new JMSCondition(false, name), true);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 27 04:18:56 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Sat, 27 Jun 2009 04:18:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14539415.1246090736888.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Kennard reopened JBMETA-208:
------------------------------------



> If you try describing EJB3 bean in EJB2 ejb-jar.xml you should get an error during deployment.

Yes you should, but you don't.

Please reopen this issue. If you DID get an error during deployment, I would agree the current 'namespace versus DTD' handling is fine. As it is, you get an obscure JBMETA-4 warning and everything fails silently.


> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 27 04:52:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Sat, 27 Jun 2009 04:52:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1670) Disallow
 forward slashes in jms destinations
Message-ID: <15439568.1246092776416.JavaMail.jira@cloud.prod.atl2.jboss.com>

Disallow forward slashes in jms destinations
--------------------------------------------

                 Key: JBMESSAGING-1670
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1670
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
            Assignee: Tim Fox
             Fix For: 2.0.0


We need to disallow forward slashes in JMS destination names since they won't be able to be deployed in JNDI since the slash will be interperted as a subcontext by JNDI

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 27 04:54:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Sat, 27 Jun 2009 04:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1671) Consider
 storing JMS destinations in their own journal instance
Message-ID: <11315556.1246092896416.JavaMail.jira@cloud.prod.atl2.jboss.com>

Consider storing JMS destinations in their own journal instance
---------------------------------------------------------------

                 Key: JBMESSAGING-1671
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1671
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
            Assignee: Tim Fox
             Fix For: 2.0.0


We should consider storing JMS destinations in their own journal instance, and automatically deploy them into JNDI and management from this. This would mean that any JMS destinations created via the management interface would get redeployed on startup, which is not currently the case

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 27 05:35:56 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Sat, 27 Jun 2009 05:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4422648.1246095356857.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474073#action_12474073 ] 

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

The deployment descriptor dictates what and how should be deployed (that's why it is called deployment descriptor). EJB2 deployment descriptor means the deployment is EJB2. And since the descriptor is empty you get nothing deployed. If you did try to describe an EJB3 bean in EJB2 deployment descriptor you would get an error. Do you have a testcase that shows that's not the case?

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 27 09:53:56 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Sat, 27 Jun 2009 09:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <8585481.1246110836918.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474075#action_12474075 ] 

Ian Springer commented on JBAS-7032:
------------------------------------

Hi John,

Yeah, that would be a workaround. However, you really should not have to do this (i.e. deploying the admin-console should not force you to change any of your other apps), so there is probably something that needs fixing in the admin-console's classloading configuration and/or JBAS itself. As you can see, this issue has been raised to Blocker, so we consider this an important issue to get to the bottom of.


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 27 09:53:57 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 27 Jun 2009 09:53:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1000) COMPRESS corrupts
	some messages
In-Reply-To: <7560851.1245854756549.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <710002.1246110837087.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1000:
---------------------------

    Fix Version/s: 2.4.7
                   2.6.11
                   2.8


> COMPRESS corrupts some messages
> -------------------------------
>
>                 Key: JGRP-1000
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1000
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.5
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> COMPRESS.down() stores the compressed message in a temporary buffer the same size as the original message.
> If the compressed size of a message is larger than the original, then part of the message is lost, with no errors reported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jun 27 09:58:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 27 Jun 2009 09:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1000) COMPRESS corrupts
	some messages
In-Reply-To: <7560851.1245854756549.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23889151.1246111136499.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474077#action_12474077 ] 

Bela Ban commented on JGRP-1000:
--------------------------------

It sucks that a compressed payload would be *greater* than the uncompressed payload ! Therefore I suggest the following change: 
- Allocate a buffer with the length computed as mentioned above
- If the compressed payload is >= the regular payload, we send the regular payload and don't attach a CompressHeader
- Else we send the compressed payload (with a CompressHeader)

WDYT ?

> COMPRESS corrupts some messages
> -------------------------------
>
>                 Key: JGRP-1000
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1000
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.5
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> COMPRESS.down() stores the compressed message in a temporary buffer the same size as the original message.
> If the compressed size of a message is larger than the original, then part of the message is lost, with no errors reported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 00:47:57 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Sun, 28 Jun 2009 00:47:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10474790.1246164477242.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474091#action_12474091 ] 

Richard Kennard commented on JBMETA-208:
----------------------------------------

> If you did try to describe an EJB3 bean in EJB2 deployment descriptor you would get an error

Fair enough. But in general EJB3 beans are not described in the deployment descriptor: they are described with an annotation on the class.

If you have a bean annotated @Stateful or @Stateless in your JAR, but your JAR has an EJB2 deployment descriptor, you should get an error. But you don't. You DO get a JBMETA-4 warning, but this is not very clear as to what the problem is.

I am sorry I haven't been explaining myself very well. I hope the problem is now clear. What happened was I upgraded a JBoss 4.2.3.GA app to JBoss 5.1.0. The app used EJB3 annotations but forgot the namespace on the ejb-jar.xml (hence accidentally making it an EJB2 descriptor). This worked fine on JBoss 4.2.3.GA, but JBoss 5.1.0 is clearly stricter. This is a good thing, but throwing an error would be useful for stupid people like me!


> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <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">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 09:29:57 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Sun, 28 Jun 2009 09:29:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <14081650.1246195797117.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474096#action_12474096 ] 

John Ament commented on JBAS-7032:
----------------------------------

well, upgrading admin console to RF3.3.1 didn't work, and downgrading my apps isn't much of an option as I"m using the layout components.

I also tried to reset the classloader configuration, removing the following from jboss-web.xml in the admin-console

    <class-loading>
        <loader-repository>
            org.jboss.on:loader=embedded
            <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
        </loader-repository>
    </class-loading>

and no such luck.  the application loads now, but an error pops up when i attempt to access it.  this stack trace makes me think that the webbeans manager is somehow messing with seam's conversations.

2009-06-28 09:24:22,070 WARN  [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-1) uncaught exception, passing to exception handler
java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Conversation.instance(Conversation.java:114)
	at org.jboss.seam.faces.FacesManager.prepareBackswitch(FacesManager.java:257)
	at org.jboss.seam.jsf.SeamPhaseListener.afterRenderResponse(SeamPhaseListener.java:505)
	at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:247)
	at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:194)
	at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)
2009-06-28 09:24:22,087 ERROR [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-1) swallowing exception
java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Conversation.instance(Conversation.java:114)
	at org.jboss.seam.faces.FacesManager.prepareBackswitch(FacesManager.java:257)
	at org.jboss.seam.jsf.SeamPhaseListener.afterRenderResponse(SeamPhaseListener.java:505)
	at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:247)
	at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:194)
	at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)
2009-06-28 09:24:27,433 WARN  [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-2) uncaught exception, passing to exception handler
java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Conversation.instance(Conversation.java:114)
	at org.jboss.seam.faces.FacesManager.prepareBackswitch(FacesManager.java:257)
	at org.jboss.seam.jsf.SeamPhaseListener.afterRenderResponse(SeamPhaseListener.java:505)
	at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:247)
	at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:194)
	at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)
2009-06-28 09:24:27,455 ERROR [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-2) swallowing exception
java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Conversation.instance(Conversation.java:114)
	at org.jboss.seam.faces.FacesManager.prepareBackswitch(FacesManager.java:257)
	at org.jboss.seam.jsf.SeamPhaseListener.afterRenderResponse(SeamPhaseListener.java:505)
	at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:247)
	at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:194)
	at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)
2009-06-28 09:24:27,658 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http-127.0.0.1-8080-2) JSF1053: (Listener: org.jboss.webbeans.jsf.WebBeansPhaseListener.afterPhase(), Phase ID: RESTORE_VIEW 1,  View ID: /secure/summary.xhtml) Exception thrown during phase-listener execution: javax.context.ContextNotActiveException: No active contexts for scope type javax.context.RequestScoped
2009-06-28 09:24:27,660 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http-127.0.0.1-8080-2) org.jboss.webbeans.ManagerImpl.getContext(ManagerImpl.java:739)
org.jboss.webbeans.bean.proxy.ClientProxyMethodHandler.getProxiedInstance(ClientProxyMethodHandler.java:116)
org.jboss.webbeans.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:96)
org.jboss.webbeans.servlet.HttpSessionManager_$$_javassist_1.setSession(HttpSessionManager_$$_javassist_1.java)
org.jboss.webbeans.jsf.WebBeansPhaseListener.afterRestoreView(WebBeansPhaseListener.java:119)
org.jboss.webbeans.jsf.WebBeansPhaseListener.afterPhase(WebBeansPhaseListener.java:90)
com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:103)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
java.lang.Thread.run(Thread.java:619)

2009-06-28 09:24:27,686 ERROR [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-2) swallowing exception
javax.el.PropertyNotFoundException: Target Unreachable, identifier 'redirect' resolved to null
	at org.jboss.el.parser.AstValue.getTarget(AstValue.java:38)
	at org.jboss.el.parser.AstValue.invoke(AstValue.java:95)
	at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
	at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
	at org.jboss.seam.core.Events.raiseEvent(Events.java:68)
	at org.jboss.seam.navigation.Pages.notLoggedIn(Pages.java:657)
	at org.jboss.seam.navigation.Pages.redirectToLoginView(Pages.java:572)
	at org.jboss.seam.navigation.Pages.preRender(Pages.java:344)
	at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
	at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
	at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
	at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
	at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)
2009-06-28 09:24:27,725 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http-127.0.0.1-8080-2) JSF1053: (Listener: org.jboss.webbeans.jsf.WebBeansPhaseListener.beforePhase(), Phase ID: RENDER_RESPONSE 6,  View ID: /secure/summary.xhtml) Exception thrown during phase-listener execution: javax.context.ContextNotActiveException: No active contexts for scope type javax.context.RequestScoped
2009-06-28 09:24:27,730 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http-127.0.0.1-8080-2) org.jboss.webbeans.ManagerImpl.getContext(ManagerImpl.java:739)
org.jboss.webbeans.bean.proxy.ClientProxyMethodHandler.getProxiedInstance(ClientProxyMethodHandler.java:116)
org.jboss.webbeans.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:96)
org.jboss.webbeans.conversation.ConversationImpl_$$_javassist_2.isLongRunning(ConversationImpl_$$_javassist_2.java)
org.jboss.webbeans.jsf.WebBeansPhaseListener.beforeRenderReponse(WebBeansPhaseListener.java:71)
org.jboss.webbeans.jsf.WebBeansPhaseListener.beforePhase(WebBeansPhaseListener.java:60)
com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
java.lang.Thread.run(Thread.java:619)

2009-06-28 09:24:27,762 WARN  [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-2) uncaught exception, passing to exception handler
java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Conversation.instance(Conversation.java:114)
	at org.jboss.seam.faces.FacesManager.prepareBackswitch(FacesManager.java:257)
	at org.jboss.seam.jsf.SeamPhaseListener.afterRenderResponse(SeamPhaseListener.java:505)
	at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:247)
	at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:194)
	at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)
2009-06-28 09:24:27,810 ERROR [org.jboss.seam.jsf.SeamPhaseListener] (http-127.0.0.1-8080-2) swallowing exception
java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Conversation.instance(Conversation.java:114)
	at org.jboss.seam.faces.FacesManager.prepareBackswitch(FacesManager.java:257)
	at org.jboss.seam.jsf.SeamPhaseListener.afterRenderResponse(SeamPhaseListener.java:505)
	at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:247)
	at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:194)
	at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 09:37:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 28 Jun 2009 09:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2145) Trunk
 5.1.0-snapshot hangs if pounded enough
Message-ID: <9231831.1246196276710.JavaMail.jira@cloud.prod.atl2.jboss.com>

Trunk 5.1.0-snapshot hangs if pounded enough
--------------------------------------------

                 Key: JBRULES-2145
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2145
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
    Affects Versions: 5.1.0.M1
         Environment: quad core, ubuntu 9.04
            Reporter: Geoffrey De Smet
            Assignee: Edson Tirelli
            Priority: Critical
             Fix For: 5.1.0.M1


To reproduce:

svn checkout <drools>
edit drools/drools-solver/pom.xml and comment out the dependencies on 5.0.1
(1) run PatientAdmissionScheduleApp in the working directory drools/drools-solver/drools-solver-examples
Click load testdata01.xml
Click solve

In the output, you 'll see something like this:
Trunk is bugged 35/652
Trunk is bugged 36/652
Trunk is bugged 37/652

At some point it might hang before it reaches 652. It does not happen every time, so try again it does reach 652.
I've seen it occur about 1 out of 3 times.

And if it hangs, it really hangs: all 4 of my CPU's are not buzy etc. Definitely a race condition.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 09:42:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 28 Jun 2009 09:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2145) Trunk
 5.1.0-snapshot hangs if pounded enough
In-Reply-To: <9231831.1246196276710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11643175.1246196576506.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474097#action_12474097 ] 

Geoffrey De Smet commented on JBRULES-2145:
-------------------------------------------

cannot reproduce on 5.0.1, so it's only the trunk that is bugged

> Trunk 5.1.0-snapshot hangs if pounded enough
> --------------------------------------------
>
>                 Key: JBRULES-2145
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2145
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.1.0.M1
>         Environment: quad core, ubuntu 9.04
>            Reporter: Geoffrey De Smet
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.1.0.M1
>
>
> To reproduce:
> svn checkout <drools>
> edit drools/drools-solver/pom.xml and comment out the dependencies on 5.0.1
> (1) run PatientAdmissionScheduleApp in the working directory drools/drools-solver/drools-solver-examples
> Click load testdata01.xml
> Click solve
> In the output, you 'll see something like this:
> Trunk is bugged 35/652
> Trunk is bugged 36/652
> Trunk is bugged 37/652
> At some point it might hang before it reaches 652. It does not happen every time, so try again it does reach 652.
> I've seen it occur about 1 out of 3 times.
> And if it hangs, it really hangs: all 4 of my CPU's are not buzy etc. Definitely a race condition.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 09:46:56 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 28 Jun 2009 09:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2145) Trunk
 5.1.0-snapshot hangs if pounded enough
In-Reply-To: <9231831.1246196276710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3061593.1246196816990.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474098#action_12474098 ] 

Geoffrey De Smet commented on JBRULES-2145:
-------------------------------------------

by depending from drools-solver on mvn repository drools-api/core/compiler timestamped snapshots you might be able to determine which svn commit caused this race condition... otherwise it could be like finding a needle in a haystack

> Trunk 5.1.0-snapshot hangs if pounded enough
> --------------------------------------------
>
>                 Key: JBRULES-2145
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2145
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.1.0.M1
>         Environment: quad core, ubuntu 9.04
>            Reporter: Geoffrey De Smet
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.1.0.M1
>
>
> To reproduce:
> svn checkout <drools>
> edit drools/drools-solver/pom.xml and comment out the dependencies on 5.0.1
> (1) run PatientAdmissionScheduleApp in the working directory drools/drools-solver/drools-solver-examples
> Click load testdata01.xml
> Click solve
> In the output, you 'll see something like this:
> Trunk is bugged 35/652
> Trunk is bugged 36/652
> Trunk is bugged 37/652
> At some point it might hang before it reaches 652. It does not happen every time, so try again it does reach 652.
> I've seen it occur about 1 out of 3 times.
> And if it hangs, it really hangs: all 4 of my CPU's are not buzy etc. Definitely a race condition.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 10:55:57 2009
From: jira-events at lists.jboss.org (Martin Kouba (JIRA))
Date: Sun, 28 Jun 2009 10:55:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6532) TCLFilter doesn't
 work in jboss 5 with war's in any documented way
In-Reply-To: <30315317.1235141804672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19029535.1246200957393.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474099#action_12474099 ] 

Martin Kouba commented on JBAS-6532:
------------------------------------

Actually this patch does not work for me in 5.1.0.GA. Probably because of jboss-logging-log4j was updated to 2.1.0.GA - https://jira.jboss.org/jira/browse/JBAS-6898.

> TCLFilter doesn't work in jboss 5 with war's in any documented way
> ------------------------------------------------------------------
>
>                 Key: JBAS-6532
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6532
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: jdk 6, linux
>            Reporter: robert lazarski
>            Assignee: Scott M Stark
>         Attachments: JBAS-6532.patch, jboss-logging-log4j.jar
>
>
> Reading this doc: 
> http://www.jboss.org/community/docs/DOC-12203
> Indicates a *-exp.war syntax is needed for TCLFilter war use, but there are no files of that type on my system running jboss 5. I've tried all the possible combinations I can think of, posted the problem to the forum, and the result is always that the file sizes and contents of the log files generated are exactly the same for the different war's, ie, no separated content. Here's my current config: 
> <appender name="penguinLog" class="org.apache.log4j.FileAppender">
>       <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler>
>       <param name="Append" value="false"/>
>       <param name="File" value="${jboss.server.home.dir}/log/penguinLog.log"/>
>       <layout class="org.apache.log4j.PatternLayout">
>          <param name="ConversionPattern" value="%d %-5p %c{1} %m%n"/>
>       </layout>
>       <filter class="org.jboss.logging.filter.TCLFilter">
>          <param name="AcceptOnMatch" value="true"/>
>          <param name="DeployURL" value="penguin"/>
>       </filter>
>    </appender>
>    <appender name="wtfLog" class="org.apache.log4j.FileAppender">
>       <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler>
>       <param name="Append" value="false"/>
>       <param name="File" value="${jboss.server.home.dir}/log/wtfLog.log"/>
>       <layout class="org.apache.log4j.PatternLayout">
>          <param name="ConversionPattern" value="%d %-5p %c{1} %m%n"/>
>       </layout>
>       <filter class="org.jboss.logging.filter.TCLFilter">
>          <param name="AcceptOnMatch" value="true"/>
>          <param name="DeployURL" value="wtf-exp.war"/>
>       </filter>
>    </appender>
>    <root>
>       <appender-ref ref="CONSOLE"/>
>       <appender-ref ref="FILE"/>
>       <appender-ref ref="penguinLog"/>
>       <appender-ref ref="wtfLog"/>
>    </root>
> 	

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 11:53:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sun, 28 Jun 2009 11:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1004) GroupRequest: don't
 ignore InterruptedException
Message-ID: <32897668.1246204436416.JavaMail.jira@cloud.prod.atl2.jboss.com>

GroupRequest: don't ignore InterruptedException
-----------------------------------------------

                 Key: JGRP-1004
                 URL: https://jira.jboss.org/jira/browse/JGRP-1004
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 2.6.11, 2.8


[Mircea]

This is related to https://jira.jboss.org/jira/browse/ISPN-38 (Early distributed deadlock detection).
When I determine that a deadlock scenario happens, I try to interrupt a tx originated locally. This translates to an thread.interrupt() call on a thread that is replicating to other caches. The issue is that this call is ignored in jgroups's GroupRequest:
   private boolean collectResponses(long timeout)  {
               .....
               if(timeout > 0) {
                   try {
                       completed.await(timeout, TimeUnit.MILLISECONDS); //LINE 552
                   }
                   catch(Exception e) {
                   }
               }
               ....
  }

So my call to interrupt is ignored (line 552) and the collectResponses method will only return after timeout elapses - not good for me, as I want the method to return immediately if thread is interrupted.
Would it be possible to enhance the code to be aware of interrupt calls? This is in JGroups 2.8.0 Beta2. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 12:13:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sun, 28 Jun 2009 12:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1004) GroupRequest: don't
 ignore InterruptedException
In-Reply-To: <32897668.1246204436416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29290890.1246205636450.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1004.
----------------------------

    Resolution: Done


> GroupRequest: don't ignore InterruptedException
> -----------------------------------------------
>
>                 Key: JGRP-1004
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1004
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.6.11, 2.8
>
>
> [Mircea]
> This is related to https://jira.jboss.org/jira/browse/ISPN-38 (Early distributed deadlock detection).
> When I determine that a deadlock scenario happens, I try to interrupt a tx originated locally. This translates to an thread.interrupt() call on a thread that is replicating to other caches. The issue is that this call is ignored in jgroups's GroupRequest:
>    private boolean collectResponses(long timeout)  {
>                .....
>                if(timeout > 0) {
>                    try {
>                        completed.await(timeout, TimeUnit.MILLISECONDS); //LINE 552
>                    }
>                    catch(Exception e) {
>                    }
>                }
>                ....
>   }
> So my call to interrupt is ignored (line 552) and the collectResponses method will only return after timeout elapses - not good for me, as I want the method to return immediately if thread is interrupted.
> Would it be possible to enhance the code to be aware of interrupt calls? This is in JGroups 2.8.0 Beta2. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 18:47:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 28 Jun 2009 18:47:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2146) Improved process
 instance migration
Message-ID: <5708418.1246229276798.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improved process instance migration
-----------------------------------

                 Key: JBRULES-2146
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2146
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-core (flow)
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen
             Fix For: 5.1.0.M1


Process instance migration should
 - support new api
 - support nested nodes

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 20:02:56 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 28 Jun 2009 20:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2146) Improved process
 instance migration
In-Reply-To: <5708418.1246229276798.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32862410.1246233776616.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen resolved JBRULES-2146.
-------------------------------------

    Resolution: Done


> Improved process instance migration
> -----------------------------------
>
>                 Key: JBRULES-2146
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2146
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (flow)
>            Reporter: Kris Verlaenen
>            Assignee: Kris Verlaenen
>             Fix For: 5.1.0.M1
>
>
> Process instance migration should
>  - support new api
>  - support nested nodes

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 20:51:58 2009
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Sun, 28 Jun 2009 20:51:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1000) COMPRESS corrupts
	some messages
In-Reply-To: <7560851.1245854756549.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21566007.1246236718928.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474103#action_12474103 ] 

Dennis Reed commented on JGRP-1000:
-----------------------------------

That makes sense.

With your fix, the buffer size wouldn't have to change.
deflater.getTotalOut() returns the number of bytes written, so if the buffer was too small, it's equal to the buffer size.

So it could be implemented with just:

+    if ( compressed_size < length ) {
         byte[] new_payload=new byte[compressed_size];
         System.arraycopy(compressed_payload, 0, new_payload, 0, compressed_size);
         msg.setBuffer(new_payload); 
         msg.putHeader(name, new CompressHeader(length));
+    }


> COMPRESS corrupts some messages
> -------------------------------
>
>                 Key: JGRP-1000
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1000
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.5
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> COMPRESS.down() stores the compressed message in a temporary buffer the same size as the original message.
> If the compressed size of a message is larger than the original, then part of the message is lost, with no errors reported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jun 28 23:30:08 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Sun, 28 Jun 2009 23:30:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1617) JBoss should
 rely on JMSCorrelationID as String as per JMS1.1 spec and handle
 java.lang.UnsupportedOperationException
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9805558.1246246208242.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1617:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> JBoss should rely on JMSCorrelationID as String as per JMS1.1 spec and handle java.lang.UnsupportedOperationException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Sun Jun 28 23:32:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Sun, 28 Jun 2009 23:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1617) JBoss should
 rely on JMSCorrelationID as String as per JMS1.1 spec and handle
 java.lang.UnsupportedOperationException
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10626149.1246246376574.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1617:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> JBoss should rely on JMSCorrelationID as String as per JMS1.1 spec and handle java.lang.UnsupportedOperationException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 02:16:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 29 Jun 2009 02:16:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1617) JBoss
 should rely on
 JMSCorrelationID as String as per JMS1.1 spec and handle
 java.lang.UnsupportedOperationException
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8711941.1246256216598.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474111#action_12474111 ] 

Howard Gao commented on JBMESSAGING-1617:
-----------------------------------------

As using byte[] as correlation ID is not portable, we can drop it. But if the foreign message has a string correlation ID, it should be preserved.


> JBoss should rely on JMSCorrelationID as String as per JMS1.1 spec and handle java.lang.UnsupportedOperationException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 02:54:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 29 Jun 2009 02:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1664) Ordering
 Group is broken
 on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23330519.1246258496723.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reopened JBMESSAGING-1664:
-------------------------------------



the problem still exists as per the user.

> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 02:54:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 29 Jun 2009 02:54:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-984) JGroups can not parse
 IPV6 literals in TCPPING protocol configuration
In-Reply-To: <7188979.1242741125294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8605246.1246258496601.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban closed JGRP-984.
-------------------------

    Resolution: Cannot Reproduce Bug


Please reopen with concise instructions as to how to reproduce if this bug still exists

> JGroups can not parse IPV6 literals in TCPPING protocol configuration
> ---------------------------------------------------------------------
>
>                 Key: JGRP-984
>                 URL: https://jira.jboss.org/jira/browse/JGRP-984
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.6
>            Reporter: Brian Stansberry
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> ON JBPAPP-2013 Dominik Pospisil reports the IPv6 address parsing fix in 2.4.6 doesn't handle TCPPING:
> Both
> <TCPPING initial_hosts="::1[7810],fec0::f101:21a:a0ff:fea0:d745[7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> and
> <TCPPING initial_hosts="[::1][7810],[fec0::f101:21a:a0ff:fea0:d745][7810]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/>
> fails with:
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "::1"
> 16:57:56,443 ERROR [TCPPING] exeption is java.lang.NumberFormatException: For input string: "fec0::f101:21a:a0ff:fea0:d745"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 02:56:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 29 Jun 2009 02:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-1003) deadlock in TP.send -
 socket write
 hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30246218.1246258616877.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban closed JGRP-1003.
--------------------------

    Resolution: Won't Fix


This should work with use_send_queues="true". Please reopen if not. Note that the entire TCP / TCP_NIO impl will get rewritten once we switch to JDK 1.7 as baseline (NIO2)

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 03:44:56 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 29 Jun 2009 03:44:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-924) Shared transport:
 RouterStub cannot connect to 'channel_name'
In-Reply-To: <25276044.1236254962608.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10240132.1246261496883.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JGRP-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474119#action_12474119 ] 

Bela Ban commented on JGRP-924:
-------------------------------

ThreadLocal won't work if message bundling is enabled, because a separate thread (timer thread) might send the bundled messages.

> Shared transport: RouterStub cannot connect to 'channel_name'
> -------------------------------------------------------------
>
>                 Key: JGRP-924
>                 URL: https://jira.jboss.org/jira/browse/JGRP-924
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.8
>
>
> Channel name doesn't mean much in a shared transport. RouterStub.connect(channel_name) won't work

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 04:36:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 29 Jun 2009 04:36:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1617) JBoss
 should rely on
 JMSCorrelationID as String as per JMS1.1 spec and handle
 java.lang.UnsupportedOperationException
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18118681.1246264617062.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474128#action_12474128 ] 

Tim Fox commented on JBMESSAGING-1617:
--------------------------------------

I can't understand what this JIRA is about.. Can someone explain?

> JBoss should rely on JMSCorrelationID as String as per JMS1.1 spec and handle java.lang.UnsupportedOperationException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 04:41:56 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 29 Jun 2009 04:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1617) JBoss
 should rely on
 JMSCorrelationID as String as per JMS1.1 spec and handle
 java.lang.UnsupportedOperationException
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <811141.1246264916552.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474129#action_12474129 ] 

Tim Fox commented on JBMESSAGING-1617:
--------------------------------------

The description doesn't actually explain what the perceived problem is. I just see a long quote from the JMS spec followed by some talk about a new constructor.

> JBoss should rely on JMSCorrelationID as String as per JMS1.1 spec and handle java.lang.UnsupportedOperationException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 05:13:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 29 Jun 2009 05:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7060) Unable to set
 attributes for MBeans with quoted object name
Message-ID: <18359891.1246266836533.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unable to set attributes for MBeans with quoted object name
-----------------------------------------------------------

                 Key: JBAS-7060
                 URL: https://jira.jboss.org/jira/browse/JBAS-7060
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMX/Web Console
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Jeff Mesnil
            Assignee: Darran Lofthouse


While integration JBoss Messaging 2.0.0.Beta3 to AS 5.1.0.GA, I found an issue when I want to update attributes for one of our MBeans which has a quoted ObjectName. The ObjectName is not properly encoded by the Servlet and an exception is thrown by the MBean registry which claims the mbean is not registered.

The ObjectName is: module=JMS,name="DLQ",type=Queue
  - the *name* value is quoted

When I display this mbean in the jmx console, the corresponding form to update the attributes has a field:

<input type="hidden" name="name" value="org.jboss.messaging:module=JMS,type=Queue,name="DLQ"" /> 

The quotes of the ObjectNames are not properly encoded which results in a bogus object name when applying changes:

0:57:16,082 ERROR [[HtmlAdaptor]] "Servlet.service()" pour la servlet HtmlAdaptor a genere une exception
javax.management.InstanceNotFoundException: org.jboss.messaging:module=JMS,type=Queue,name= is not registered.
	at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:526)
	at org.jboss.mx.server.MBeanServerImpl.getMBeanInfo(MBeanServerImpl.java:675)
	at org.jboss.jmx.adaptor.control.Server.setAttributes(Server.java:172)
	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$5.run(HtmlAdaptorServlet.java:403)
	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$5.run(HtmlAdaptorServlet.java:401)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.setAttributes(HtmlAdaptorServlet.java:399)
	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.updateAttributes(HtmlAdaptorServlet.java:259)
	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:102)
	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:86)

This bug prevents to update many MBeans required to managed properly JBoss Messaging when it is integrated in the AS.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 05:17:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 29 Jun 2009 05:17:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1672) AS 5 MBean
 Server integration
Message-ID: <32421204.1246267076495.JavaMail.jira@cloud.prod.atl2.jboss.com>

AS 5 MBean Server integration
-----------------------------

                 Key: JBMESSAGING-1672
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1672
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Configuration and Management
    Affects Versions: 2.0.0.beta3
         Environment: JBoss AS 5.1.0.GA
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 2.0.0


When JBoss Messaging is integrated in AS 5, it should use AS 5's MBeanServer instead of the JVM's Platform MBeanServer to ensure JBoss Messaging is manageable through AS 5 jmx-console

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 05:23:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 29 Jun 2009 05:23:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1617) JBoss
 should rely on
 JMSCorrelationID as String as per JMS1.1 spec and handle
 java.lang.UnsupportedOperationException
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3264983.1246267436615.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474140#action_12474140 ] 

Howard Gao commented on JBMESSAGING-1617:
-----------------------------------------

Hi Tim,

My understanding is that some other providers always throw exception when the set/get JMSCorrelationIDAsBytes get called and the application have to handle the exception whenever a JBossMessage(foreign, id) is constructed. So it suggested we don't use byte[] ID in the constructor as the spec says it may cause portability problem. 

> JBoss should rely on JMSCorrelationID as String as per JMS1.1 spec and handle java.lang.UnsupportedOperationException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 05:38:57 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 29 Jun 2009 05:38:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1617) JBM does not
 handle
 java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes()
 when copying a foreign message.
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20020094.1246268337314.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1617:
---------------------------------

        Summary: JBM does not handle java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes() when copying a foreign message.  (was: JBoss should rely on JMSCorrelationID as String as per JMS1.1 spec and handle java.lang.UnsupportedOperationException)
    Description: 
Some providers can throw UnsupportedOperationException from getCorrelationIDBytes(). This is called in the foreign message constructor of a JBM message. Currently JBM will fail to copy the message since the exception is not handled.


JavaTM Message Service Specification Version 1.1 :

" 3.4.5 JMSCorrelationID

A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.

JMSCorrelationID can hold one of the following:

? A provider-specific message ID

? An application-specific String

? A provider-native byte[] value

Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.

In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.

If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.

* Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"

So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :

/**
    * A copy constructor for non-JBoss Messaging JMS messages.
    */   
   public JBossMessage(Message foreign, long messageID) throws JMSException
   {
      super(messageID);

      setJMSTimestamp(foreign.getJMSTimestamp());

      try
      {
         byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
         setJMSCorrelationIDAsBytes(corrIDBytes);
      }
      catch(JMSException e)
      {
         // specified as String
         String corrIDString = foreign.getJMSCorrelationID();
         if (corrIDString != null)
         {
            setJMSCorrelationID(corrIDString);
         }
      }
      
      setJMSReplyTo(foreign.getJMSReplyTo());
      setJMSDestination(foreign.getJMSDestination());
      setJMSDeliveryMode(foreign.getJMSDeliveryMode());
      setJMSExpiration(foreign.getJMSExpiration());
      setJMSPriority(foreign.getJMSPriority());
      setJMSType(foreign.getJMSType());

      for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
      {
         String name = (String)props.nextElement();
         
         Object prop = foreign.getObjectProperty(name);

         this.setObjectProperty(name, prop);                       
      }
   }



  was:
JavaTM Message Service Specification Version 1.1 :

" 3.4.5 JMSCorrelationID

A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.

JMSCorrelationID can hold one of the following:

? A provider-specific message ID

? An application-specific String

? A provider-native byte[] value

Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.

In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.

If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.

* Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"

So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :

/**
    * A copy constructor for non-JBoss Messaging JMS messages.
    */   
   public JBossMessage(Message foreign, long messageID) throws JMSException
   {
      super(messageID);

      setJMSTimestamp(foreign.getJMSTimestamp());

      try
      {
         byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
         setJMSCorrelationIDAsBytes(corrIDBytes);
      }
      catch(JMSException e)
      {
         // specified as String
         String corrIDString = foreign.getJMSCorrelationID();
         if (corrIDString != null)
         {
            setJMSCorrelationID(corrIDString);
         }
      }
      
      setJMSReplyTo(foreign.getJMSReplyTo());
      setJMSDestination(foreign.getJMSDestination());
      setJMSDeliveryMode(foreign.getJMSDeliveryMode());
      setJMSExpiration(foreign.getJMSExpiration());
      setJMSPriority(foreign.getJMSPriority());
      setJMSType(foreign.getJMSType());

      for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
      {
         String name = (String)props.nextElement();
         
         Object prop = foreign.getObjectProperty(name);

         this.setObjectProperty(name, prop);                       
      }
   }





I changed the title and added a short description so it's more obvious what this JIRA is about.

> JBM does not handle java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes() when copying a foreign message.
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Some providers can throw UnsupportedOperationException from getCorrelationIDBytes(). This is called in the foreign message constructor of a JBM message. Currently JBM will fail to copy the message since the exception is not handled.
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 07:48:56 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 29 Jun 2009 07:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1673) MBean
 operations which
 requires a filter should treat an empty string as a null filter
Message-ID: <9927505.1246276136505.JavaMail.jira@cloud.prod.atl2.jboss.com>

MBean operations which requires a filter should treat an empty string as a null filter
--------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1673
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1673
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Configuration and Management
    Affects Versions: 2.0.0.beta3
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 2.0.0


e.g. listMessages requires a filter parameter.

Currently if an empty string is passed, it'll raise an exception when a filter is created from this string.
Instead the MBean should check if the parameter is null or an empty string and treat it as a null filter.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 09:01:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 09:01:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2147)
 NullPointerException in
 org.drools.rule.builder.PatternBuilder.getDeclarationsMap()
Message-ID: <26204962.1246280516966.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointerException in org.drools.rule.builder.PatternBuilder.getDeclarationsMap()
-----------------------------------------------------------------------------------

                 Key: JBRULES-2147
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2147
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler (expert)
    Affects Versions: 5.0.1.FINAL
         Environment: java 1.5, linux x64, jboss 4.0.5
            Reporter: Juergen none
            Assignee: Mark Proctor


I understand my rules/fact objects might not be proper (still searching), but resulting in a NullPointerException is not proper as well

entry.getValue().getExtractor().getExtractToClass() yields NullPointerException, because entry.getValue().getExtractor() is null

eclipse debug variable:

value	org.drools.rule.Declaration  (id=502)	
	identifier	"schoolForm" (id=501)	
	internalFact	false	
	pattern	org.drools.rule.Pattern  (id=508)	
		behaviors	null	
		constraints	java.util.ArrayList<E>  (id=520)	
		declaration	org.drools.rule.Declaration  (id=521)	
		declarations	java.util.HashMap<K,V>  (id=522)	
		index	1	
		objectType	org.drools.base.ClassObjectType  (id=524)	
		offset	0	
		source	null	
	readAccessor	null	

Stacktrace:
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
...
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException
        at org.drools.rule.builder.PatternBuilder.getDeclarationsMap(PatternBuilder.java:641)
        at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:574)
        at org.drools.rule.builder.PatternBuilder.buildConstraint(PatternBuilder.java:244)
        at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:196)
        at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:104)
        at org.drools.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:69)
        at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:68)
        at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:1159)
        at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:649)
        at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:278)
        at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:158)
        at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:93)
...


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 09:18:57 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Mon, 29 Jun 2009 09:18:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-985) Flush and join
 problems during constant node failures and constant joins
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17461343.1246281537030.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic updated JGRP-985:
-------------------------------------

    Summary: Flush and join problems during constant node failures and constant joins  (was: Admin  Join problem -GMS flush by coordinator failed)


> Flush and join problems during constant node failures and constant joins
> ------------------------------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 09:22:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 09:22:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2147)
 NullPointerException in
 org.drools.rule.builder.PatternBuilder.getDeclarationsMap()
In-Reply-To: <26204962.1246280516966.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21056488.1246281776577.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474167#action_12474167 ] 

Juergen none commented on JBRULES-2147:
---------------------------------------

was a type: attribute name was schoolType, not schoolForm
no NullPointerException after replacing
still, could be better handled

> NullPointerException in org.drools.rule.builder.PatternBuilder.getDeclarationsMap()
> -----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2147
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2147
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.0.1.FINAL
>         Environment: java 1.5, linux x64, jboss 4.0.5
>            Reporter: Juergen none
>            Assignee: Mark Proctor
>
> I understand my rules/fact objects might not be proper (still searching), but resulting in a NullPointerException is not proper as well
> entry.getValue().getExtractor().getExtractToClass() yields NullPointerException, because entry.getValue().getExtractor() is null
> eclipse debug variable:
> value	org.drools.rule.Declaration  (id=502)	
> 	identifier	"schoolForm" (id=501)	
> 	internalFact	false	
> 	pattern	org.drools.rule.Pattern  (id=508)	
> 		behaviors	null	
> 		constraints	java.util.ArrayList<E>  (id=520)	
> 		declaration	org.drools.rule.Declaration  (id=521)	
> 		declarations	java.util.HashMap<K,V>  (id=522)	
> 		index	1	
> 		objectType	org.drools.base.ClassObjectType  (id=524)	
> 		offset	0	
> 		source	null	
> 	readAccessor	null	
> Stacktrace:
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
> ...
>         at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.NullPointerException
>         at org.drools.rule.builder.PatternBuilder.getDeclarationsMap(PatternBuilder.java:641)
>         at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:574)
>         at org.drools.rule.builder.PatternBuilder.buildConstraint(PatternBuilder.java:244)
>         at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:196)
>         at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:104)
>         at org.drools.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:69)
>         at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:68)
>         at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:1159)
>         at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:649)
>         at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:278)
>         at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:158)
>         at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:93)
> ...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 09:43:56 2009
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Mon, 29 Jun 2009 09:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-2389) Preferences
 values are not getting replicated in clustered setup
In-Reply-To: <12697615.1241691166584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10139836.1246283036808.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Putz resolved JBPORTAL-2389.
-----------------------------------

    Fix Version/s: 2.7.3 Final
       Resolution: Done


> Preferences values are not getting replicated in clustered setup
> ----------------------------------------------------------------
>
>                 Key: JBPORTAL-2389
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2389
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.7.2 Final
>         Environment: two clustered instances with a shared database
>            Reporter: Martin Putz
>            Assignee: Martin Putz
>             Fix For: 2.7.3 Final
>
>         Attachments: SimplestHelloWorldWithPreferences.zip
>
>
> Any change in portlet preferences on one of the servers (using Admin Portal) is not getting reflected on the other cluster nodes. 
> Steps to replicate this is:
> 1. Develop a portlet with some preferences (Note: an extended version of the SimplestHelloWorldPortlet is attached)
> 2. Deploy the portlet war on 2 nodes running under cluster.
> 3. Use SERVER1 to change the preference value
> 4. Hit SERVER1 to see that portlet and preferences value printed on stdout.
> 5. Hit SERVER2 and verify the preferences. This will print old value.
> 6. Change the same preference on SERVER2 and see StaleStateException.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 09:43:56 2009
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Mon, 29 Jun 2009 09:43:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-2389) Preferences
 values are not getting replicated in clustered setup
In-Reply-To: <12697615.1241691166584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12293019.1246283036633.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Putz reassigned JBPORTAL-2389:
-------------------------------------

    Assignee: Martin Putz  (was: Thomas Heute)


> Preferences values are not getting replicated in clustered setup
> ----------------------------------------------------------------
>
>                 Key: JBPORTAL-2389
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2389
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.7.2 Final
>         Environment: two clustered instances with a shared database
>            Reporter: Martin Putz
>            Assignee: Martin Putz
>             Fix For: 2.7.3 Final
>
>         Attachments: SimplestHelloWorldWithPreferences.zip
>
>
> Any change in portlet preferences on one of the servers (using Admin Portal) is not getting reflected on the other cluster nodes. 
> Steps to replicate this is:
> 1. Develop a portlet with some preferences (Note: an extended version of the SimplestHelloWorldPortlet is attached)
> 2. Deploy the portlet war on 2 nodes running under cluster.
> 3. Use SERVER1 to change the preference value
> 4. Hit SERVER1 to see that portlet and preferences value printed on stdout.
> 5. Hit SERVER2 and verify the preferences. This will print old value.
> 6. Change the same preference on SERVER2 and see StaleStateException.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:07:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 29 Jun 2009 10:07:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1617) JBM does not
 handle
 java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes()
 when copying a foreign message.
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25759094.1246284476766.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1617.
-----------------------------------



done

> JBM does not handle java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes() when copying a foreign message.
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Some providers can throw UnsupportedOperationException from getCorrelationIDBytes(). This is called in the foreign message constructor of a JBM message. Currently JBM will fail to copy the message since the exception is not handled.
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 10:10:58 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 29 Jun 2009 10:10:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7061) Upgrade EJB3 to 1.1.8
Message-ID: <15406494.1246284658866.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade EJB3 to 1.1.8
---------------------

                 Key: JBAS-7061
                 URL: https://jira.jboss.org/jira/browse/JBAS-7061
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
          Components: EJB3
            Reporter: jaikiran pai
            Assignee: jaikiran pai
             Fix For: JBossAS-5.2.0.Beta1


Upgrade to the latest released EJB3 1.1.8 version.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:10:59 2009
From: jira-events at lists.jboss.org (Oleg Stepanov (JIRA))
Date: Mon, 29 Jun 2009 10:10:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7062) Number of options
 and behaviour
 of login modules should be extended to allow complex login configurations
Message-ID: <28228803.1246284659542.JavaMail.jira@cloud.prod.atl2.jboss.com>

Number of options and behaviour of login modules should be extended to allow complex login configurations

-----------------------------------------------------------------------------------------------------------

                 Key: JBAS-7062
                 URL: https://jira.jboss.org/jira/browse/JBAS-7062
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA, JBossAS-4.2.3.GA, JBossAS-4.2.2.GA
         Environment: OS: Windows XP, JDK: Sun 1.6.0 Update 10, JBoss AS: 4.2.2.GA
            Reporter: Oleg Stepanov
            Assignee: Anil Saldhana
            Priority: Optional


With the current AbstractLoginModule/UsernamePasswordLoginModule design (which all the rest modules are sublcasses of) it is impossible to compose complex login configurations.
Consider the following scenario: there are two authentication subsystems, the database and LDAP. Let's say that database stores passwords being SHA1 hashed while LDAP instance uses MD5. For this case we could have used the following (for now yet imaginary) configuration of login modules:
0. ClientLoginModule. Used on the client side to push credentials into SecurityAssociations for passing along with EJB calls.
1. DatabaseServerLoginModule with SHA1 hash option and sufficient flag
2. ModifyPasswordLoginModule (subclass of UsernamePasswordLoginModule) that a) hashes password, b) adds {scheme} prefix to the hashed password as required by the section 5.3 of RFC2307 and c) stores the resulting password in the shared state accessible by the following modules.
3. LdapLoginModule with required flag and (at least the guess would be) the useFirstPass option.

With the current implementation it won't work. If we use useFirstPass option for any module and it finds shared credentials then no actual login is ever performed. Moreover, there's no way to tell the specific module that credentials should be taken from a callback handler but still stored in the shared state (or vice versa).

Proposed is to add more options to affect a login module's behavior:
* useInternalPass - if set to true, the module will try to use credentials stored under private keys in the sharedState instead of useFirstPass keys
* saveSharedPass - if true, the resulting credentials will be stored under javax.security.auth.login.name and javax.security.auth.login.password keys in the sharedState map.
* saveInternalPass - if true, the resulting credentials will be stored under private keys in the sharedState map (independently of useFirstPass flag).
* forceLogin - if true, the module will attempt to perform the login operation even if credentials were read from the sharedState.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:12:56 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 29 Jun 2009 10:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7063) Upgrade EJB3 to 1.1.8
Message-ID: <31881366.1246284776868.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade EJB3 to 1.1.8
---------------------

                 Key: JBAS-7063
                 URL: https://jira.jboss.org/jira/browse/JBAS-7063
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
            Reporter: jaikiran pai
            Assignee: jaikiran pai
             Fix For: JBossAS-6.0.0.Alpha1


Upgrade to the latest released EJB3 1.1.8 version.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:12:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 29 Jun 2009 10:12:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6934) Tests in
 org.jboss.test.cluster failing with IBM JDK 1.5 - Failed to start
 cluster/http/jboss-web-test-service.xml
In-Reply-To: <23484241.1242648377491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <79473.1246284777633.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6934.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> Tests in org.jboss.test.cluster failing with IBM JDK 1.5 - Failed to start cluster/http/jboss-web-test-service.xml
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6934
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6934
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Some clustered tests are failing with this error message:
> Failed to start cluster/http/jboss-web-test-service.xml
> org.jboss.cache.pojo.PojoCacheException: Failed to start cluster/http/jboss-web-test-service.xml
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.<init>(PojoCacheImpl.java:63)
> 	at org.jboss.cache.pojo.PojoCacheFactory.createCache(PojoCacheFactory.java:42)
> 	at org.jboss.test.cluster.testutil.SessionTestUtil.getConfiguration(SessionTestUtil.java:147)
> 	at org.jboss.test.cluster.testutil.SessionTestUtil.createCache(SessionTestUtil.java:136)
> 	at org.jboss.test.cluster.testutil.CacheConfigTestSetup.setUp(CacheConfigTestSetup.java:84)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: org.jboss.cache.config.ConfigurationException: Unable to build interceptor chain
> 	at org.jboss.cache.factories.InterceptorChainFactory.construct(InterceptorChainFactory.java:229)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:318)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.DefaultCacheFactory.bootstrap(DefaultCacheFactory.java:155)
> 	at org.jboss.cache.DefaultCacheFactory.createAndWire(DefaultCacheFactory.java:141)
> 	at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:120)
> 	at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:93)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.<init>(PojoCacheImpl.java:58)
> Caused by: java.lang.TypeNotPresentException: Type net.jcip.annotations.ThreadSafe not present
> 	at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:38)
> 	at com.ibm.oti.reflect.AnnotationHelper.getDeclaredAnnotations(AnnotationHelper.java:50)
> 	at java.lang.Class.getDeclaredAnnotations(Class.java:1620)
> 	at java.lang.Class.getAnnotations(Class.java:1581)
> 	at java.lang.Class.getAnnotation(Class.java:1561)
> 	at java.lang.Class.isAnnotationPresent(Class.java:1648)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:252)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:325)
> 	at org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(ComponentRegistry.java:279)
> 	at org.jboss.cache.factories.ComponentRegistry$Component.injectDependencies(ComponentRegistry.java:981)
> 	at org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:255)
> 	at org.jboss.cache.factories.InterceptorChainFactory.createInterceptor(InterceptorChainFactory.java:60)
> 	at org.jboss.cache.factories.InterceptorChainFactory.buildInterceptorChain(InterceptorChainFactory.java:75)
> 	at org.jboss.cache.factories.InterceptorChainFactory.construct(InterceptorChainFactory.java:225)
> Caused by: java.lang.ClassNotFoundException: net.jcip.annotations.ThreadSafe
> 	at java.lang.Class.forName(Class.java:163)
> 	at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:33)
> This is the list of the tests failing because of this: 
> org.jboss.test.cluster.defaultcfg.simpleweb.test.AttributeBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.BuddyReplicationFailoverUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.BuddyReplicationToPassivatedSessionUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.ClusteredSessionNotificationPolicyTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.FieldBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.JBossCacheManagerConfigurationUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.ReplicationToPassivatedSessionUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionBasedMaxUnreplicatedIntervalTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionCountUnitTestCase
> org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionExpirationUnitTestCase
> In total it causes 29 failures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:12:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 29 Jun 2009 10:12:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6962)
 org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
In-Reply-To: <994948.1242838745393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15872190.1246284777917.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6962.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> org.jboss.test.cmp2.commerce.CompleteUnitTestCase failing with IBM JDK
> ----------------------------------------------------------------------
>
>                 Key: JBAS-6962
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6962
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: TEST-org.jboss.test.cmp2.commerce.CompleteUnitTestCase.xml
>
>
> With IBM JDK 1.6 the test testJBossQL fails with this message:
> Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> junit.framework.AssertionFailedError: Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id)
> 	at org.jboss.test.cmp2.commerce.QueryTest.testJBossQL(QueryTest.java:169)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)
> It's strange that with IBM 1.6 the failure does not happen in that test, but in different - testEJBQL:
> expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> junit.framework.ComparisonFailure: expected:<...pc.name = ?))) AND t[0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER AND t6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id]> but was:<...pc.name = ?))) AND t[6_l_product.id=t5_l_product_productCategories_R.PRODUCT_ID AND t1_pc.id=t5_l_product_productCategories_R.PRODUCT_CATEGORY_ID AND t1_pc.subId=t5_l_product_productCategories_R.PRODUCT_CATEGORY_SUBID AND t4_l.product=t6_l_product.id AND t0_o.ORDER_NUMBER=t4_l.ORDER_NUMBER]>
> 	at org.jboss.test.cmp2.commerce.QueryTest.testEJBQL(QueryTest.java:329)
> 	at org.jboss.test.util.ejb.EJBTestCase.runBare(EJBTestCase.java:214)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:202)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:107)
> 	at org.jboss.test.util.ejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:85)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	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:193)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
> 	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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 10:14:56 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 29 Jun 2009 10:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6968)
 org.jboss.test.spring.test.SpringClusterTestCase failing with IBM JDK 1.5
In-Reply-To: <32698421.1243001398195.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1935507.1246284896775.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6968.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> org.jboss.test.spring.test.SpringClusterTestCase failing with IBM JDK 1.5
> -------------------------------------------------------------------------
>
>                 Key: JBAS-6968
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6968
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: spring-server.log
>
>
> org.jboss.test.spring.test.SpringClusterTestCase is failing with this message:
> testStandalone	Failure	N/A
> junit.framework.AssertionFailedError
> 	at org.jboss.test.spring.test.SpringClusterTestCase.testStandalone(SpringClusterTestCase.java:43)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> In the server log you can see:
> ...
> DEPLOYMENTS IN ERROR:
>   Deployment "vfszip:/home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/lib/spring-cluster-pojos.jar/" is in error due to the following reason(s): java.lang.ClassNotFoundException: net.jcip.annotations.ThreadSafe
> ...
> Which shows that it is again the same problem with net.jcip.annotations.ThreadSafe missing in IBM JDK as discussed here JBAS-6934 and JBAS-6428.
> Solution: Ensure that jcip-annotations.jar gets copied to server/springdeployer/lib/ when the config is created.
> A. Add jcip-annotations.jar to server/default/lib (it is 2.6 KB) - springdeployer is created out of default
> B. Change testsuite/build.xml to make ant copy jcip-annotations.jar from server/all/lib/ to server/springdeployer/lib/ - don't know how to do that easily
> A. seems easier to do.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:14:57 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 29 Jun 2009 10:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6967)
 org.jboss.test.security.test.HttpsUnitTestCase failing with IBM JDK
In-Reply-To: <27953188.1242999477645.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7957651.1246284897013.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6967.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> org.jboss.test.security.test.HttpsUnitTestCase failing with IBM JDK
> -------------------------------------------------------------------
>
>                 Key: JBAS-6967
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6967
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: TEST-org.jboss.test.security.test.HttpsUnitTestCase-tests-security-basic-unit.xml
>
>
> When running the AS testsuite, this test case shows an error:
> org.jboss.test.security.test.HttpsUnitTestCase
> The error message is:
> unknown	Error	N/A
> java.lang.NullPointerException
> 	at java.security.Security.insertProviderAt(Security.java:357)
> 	at java.security.Security.addProvider(Security.java:406)
> 	at org.jboss.test.security.test.HttpsUnitTestCase$1.setUp(HttpsUnitTestCase.java:171)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> When you look in the source code, this is the line where it fails:
> Security.addProvider(SecurityProviderUtil.getJSSEProvider());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:14:57 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 29 Jun 2009 10:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1859) core tests:
 container lookups should be done after all containers are registered
Message-ID: <32556428.1246284897155.JavaMail.jira@cloud.prod.atl2.jboss.com>

core tests: container lookups should be done after all containers are registered
--------------------------------------------------------------------------------

                 Key: EJBTHREE-1859
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1859
             Project: EJB 3.0
          Issue Type: Bug
          Components: core
    Affects Versions: 1.1.8
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: 1.1.9


AbstractEJB3TestCase in registerContainer shouldn't check whether the container can be looked up. Instead, all the containers from the deployment module should be registered first. So, the lookup check should be moved up to deploySessionEjbs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:16:57 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 29 Jun 2009 10:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1859) core tests:
 container lookups should be done after all containers are registered
In-Reply-To: <32556428.1246284897155.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28729018.1246285017095.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved EJBTHREE-1859.
-----------------------------------------

    Resolution: Done


Done.

> core tests: container lookups should be done after all containers are registered
> --------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1859
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1859
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.8
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.1.9
>
>
> AbstractEJB3TestCase in registerContainer shouldn't check whether the container can be looked up. Instead, all the containers from the deployment module should be registered first. So, the lookup check should be moved up to deploySessionEjbs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:16:57 2009
From: jira-events at lists.jboss.org (Oleg Stepanov (JIRA))
Date: Mon, 29 Jun 2009 10:16:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7062) Number of options
 and behaviour
 of login modules should be extended to allow complex login configurations
In-Reply-To: <28228803.1246284659542.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <391537.1246285017476.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Stepanov updated JBAS-7062:
--------------------------------

    Attachment: modified_modules.zip


Here's the archive with modified AbstractServerLoginModule and UsernamePasswordLoginModule. The first contains methods for parsing the additional options and accessing the shared states, the second has its login method modified according to the proposed behaviour.

I believe these modifications won't affect any configurations with the new options being not specified.

> Number of options and behaviour of login modules should be extended to allow complex login configurations

> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7062
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7062
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.3.GA, JBossAS-5.1.0.GA
>         Environment: OS: Windows XP, JDK: Sun 1.6.0 Update 10, JBoss AS: 4.2.2.GA
>            Reporter: Oleg Stepanov
>            Assignee: Anil Saldhana
>            Priority: Optional
>         Attachments: modified_modules.zip
>
>
> With the current AbstractLoginModule/UsernamePasswordLoginModule design (which all the rest modules are sublcasses of) it is impossible to compose complex login configurations.
> Consider the following scenario: there are two authentication subsystems, the database and LDAP. Let's say that database stores passwords being SHA1 hashed while LDAP instance uses MD5. For this case we could have used the following (for now yet imaginary) configuration of login modules:
> 0. ClientLoginModule. Used on the client side to push credentials into SecurityAssociations for passing along with EJB calls.
> 1. DatabaseServerLoginModule with SHA1 hash option and sufficient flag
> 2. ModifyPasswordLoginModule (subclass of UsernamePasswordLoginModule) that a) hashes password, b) adds {scheme} prefix to the hashed password as required by the section 5.3 of RFC2307 and c) stores the resulting password in the shared state accessible by the following modules.
> 3. LdapLoginModule with required flag and (at least the guess would be) the useFirstPass option.
> With the current implementation it won't work. If we use useFirstPass option for any module and it finds shared credentials then no actual login is ever performed. Moreover, there's no way to tell the specific module that credentials should be taken from a callback handler but still stored in the shared state (or vice versa).
> Proposed is to add more options to affect a login module's behavior:
> * useInternalPass - if set to true, the module will try to use credentials stored under private keys in the sharedState instead of useFirstPass keys
> * saveSharedPass - if true, the resulting credentials will be stored under javax.security.auth.login.name and javax.security.auth.login.password keys in the sharedState map.
> * saveInternalPass - if true, the resulting credentials will be stored under private keys in the sharedState map (independently of useFirstPass flag).
> * forceLogin - if true, the module will attempt to perform the login operation even if credentials were read from the sharedState.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 10:32:56 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 29 Jun 2009 10:32:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1617) JBM does not
 handle
 java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes()
 when copying a foreign message.
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12465325.1246285976668.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reopened JBMESSAGING-1617:
-------------------------------------



Reopen because it drops an existing functionality and will cause backward compatibility issue.

> JBM does not handle java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes() when copying a foreign message.
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Some providers can throw UnsupportedOperationException from getCorrelationIDBytes(). This is called in the foreign message constructor of a JBM message. Currently JBM will fail to copy the message since the exception is not handled.
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 11:06:56 2009
From: jira-events at lists.jboss.org (Enrico Schenk (JIRA))
Date: Mon, 29 Jun 2009 11:06:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7064) Improve CMP mapping
	for Ingres
Message-ID: <4153775.1246288016864.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve CMP mapping for Ingres
------------------------------

                 Key: JBAS-7064
                 URL: https://jira.jboss.org/jira/browse/JBAS-7064
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: CMP service
            Reporter: Enrico Schenk
            Assignee: Alexey Loubyansky
            Priority: Minor


Improve support for the Ingres database system in the CMP service. This requires an update to the Ingres data type and function mapping in the file standardjbosscmp-jdbc.xml.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 11:10:56 2009
From: jira-events at lists.jboss.org (Enrico Schenk (JIRA))
Date: Mon, 29 Jun 2009 11:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7064) Improve CMP mapping
	for Ingres
In-Reply-To: <4153775.1246288016864.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8053220.1246288256495.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Enrico Schenk updated JBAS-7064:
--------------------------------

    Attachment: standardjbosscmp-jdbc.xml


The attached standardjbosscmp-jdbc.xml contains an updated type mapping section for Ingres.

> Improve CMP mapping for Ingres
> ------------------------------
>
>                 Key: JBAS-7064
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7064
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>            Reporter: Enrico Schenk
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>         Attachments: standardjbosscmp-jdbc.xml
>
>
> Improve support for the Ingres database system in the CMP service. This requires an update to the Ingres data type and function mapping in the file standardjbosscmp-jdbc.xml.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 11:48:09 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 29 Jun 2009 11:48:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-73) JUnit 4.6
In-Reply-To: <10026065.1236869962567.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13969962.1246290489437.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-73:
---------------------------------

    Summary: JUnit 4.6  (was: JUnit 4.5)


> JUnit 4.6
> ---------
>
>                 Key: JBJCA-73
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-73
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha1
>
>
> Test

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 12:28:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 12:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2148) make jsr94
 StatefulRuleSession keepReference configurable, not constant true
Message-ID: <16725628.1246292937006.JavaMail.jira@cloud.prod.atl2.jboss.com>

make jsr94 StatefulRuleSession keepReference configurable, not constant true
----------------------------------------------------------------------------

                 Key: JBRULES-2148
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2148
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-jsr94
    Affects Versions: 5.0.1.FINAL
            Reporter: Juergen none
            Assignee: Mark Proctor


I use stateful rule session via jsr94
i configured keepReference=false via properties file, but org.drools.jsr94.rules.StatefulRuleSessionImpl hardcoded changes it to true
org.drools.jsr94.rules.StatefulRuleSessionImpl.java::114:
conf.setKeepReference( true );

hard to call release(), via session invalidation or object finalization
I simply would like for drools not to keep a reference, something jsr94 api impl does not allow me to do

patched 4.0.7, will have to do it again for 5.0.1.FINAL

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 12:35:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 12:35:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2148) make jsr94
 StatefulRuleSession keepReference configurable, not constant true
In-Reply-To: <16725628.1246292937006.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14147031.1246293356555.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474222#action_12474222 ] 

Juergen none commented on JBRULES-2148:
---------------------------------------

sorry for duplicate, forgot I already created an issue for 4.0.7

> make jsr94 StatefulRuleSession keepReference configurable, not constant true
> ----------------------------------------------------------------------------
>
>                 Key: JBRULES-2148
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2148
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-jsr94
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Juergen none
>            Assignee: Mark Proctor
>
> I use stateful rule session via jsr94
> i configured keepReference=false via properties file, but org.drools.jsr94.rules.StatefulRuleSessionImpl hardcoded changes it to true
> org.drools.jsr94.rules.StatefulRuleSessionImpl.java::114:
> conf.setKeepReference( true );
> hard to call release(), via session invalidation or object finalization
> I simply would like for drools not to keep a reference, something jsr94 api impl does not allow me to do
> patched 4.0.7, will have to do it again for 5.0.1.FINAL

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 12:40:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 12:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2148) make jsr94
 StatefulRuleSession keepReference configurable, not constant true
In-Reply-To: <16725628.1246292937006.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20946399.1246293656813.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen none closed JBRULES-2148.
---------------------------------



> make jsr94 StatefulRuleSession keepReference configurable, not constant true
> ----------------------------------------------------------------------------
>
>                 Key: JBRULES-2148
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2148
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-jsr94
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Juergen none
>            Assignee: Mark Proctor
>
> I use stateful rule session via jsr94
> i configured keepReference=false via properties file, but org.drools.jsr94.rules.StatefulRuleSessionImpl hardcoded changes it to true
> org.drools.jsr94.rules.StatefulRuleSessionImpl.java::114:
> conf.setKeepReference( true );
> hard to call release(), via session invalidation or object finalization
> I simply would like for drools not to keep a reference, something jsr94 api impl does not allow me to do
> patched 4.0.7, will have to do it again for 5.0.1.FINAL

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 12:40:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 12:40:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2148) make jsr94
 StatefulRuleSession keepReference configurable, not constant true
In-Reply-To: <16725628.1246292937006.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1249318.1246293656639.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen none resolved JBRULES-2148.
-----------------------------------

    Resolution: Duplicate Issue


> make jsr94 StatefulRuleSession keepReference configurable, not constant true
> ----------------------------------------------------------------------------
>
>                 Key: JBRULES-2148
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2148
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-jsr94
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Juergen none
>            Assignee: Mark Proctor
>
> I use stateful rule session via jsr94
> i configured keepReference=false via properties file, but org.drools.jsr94.rules.StatefulRuleSessionImpl hardcoded changes it to true
> org.drools.jsr94.rules.StatefulRuleSessionImpl.java::114:
> conf.setKeepReference( true );
> hard to call release(), via session invalidation or object finalization
> I simply would like for drools not to keep a reference, something jsr94 api impl does not allow me to do
> patched 4.0.7, will have to do it again for 5.0.1.FINAL

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 12:56:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 12:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1168) jsr94,
 create stateful rule session, allow to set keepReference
In-Reply-To: <28027509.1188917712150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9995287.1246294616930.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen none updated JBRULES-1168:
----------------------------------

    Attachment: StatefulRuleSessionImpl.java


patched v5.0.1.FINAL org.drools.jsr94.rules.StatefulRuleSessionImpl.java I will probably use

> jsr94, create stateful rule session, allow to set keepReference
> ---------------------------------------------------------------
>
>                 Key: JBRULES-1168
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1168
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-jsr94
>    Affects Versions: 4.0.1, 5.0.1.FINAL
>            Reporter: Juergen none
>            Assignee: Mark Proctor
>            Priority: Minor
>         Attachments: StatefulRuleSessionImpl.java
>
>
> org.drools.jsr94.rules.StatefulRuleSessionImpl currently calls initSession() with constant value true for keepReference. Would be nice if this could be configurable via properties map.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 12:56:56 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 29 Jun 2009 12:56:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1168) jsr94,
 create stateful rule session, allow to set keepReference
In-Reply-To: <28027509.1188917712150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <993756.1246294616744.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen none updated JBRULES-1168:
----------------------------------

    Affects Version/s: 5.0.1.FINAL


> jsr94, create stateful rule session, allow to set keepReference
> ---------------------------------------------------------------
>
>                 Key: JBRULES-1168
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1168
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-jsr94
>    Affects Versions: 4.0.1, 5.0.1.FINAL
>            Reporter: Juergen none
>            Assignee: Mark Proctor
>            Priority: Minor
>         Attachments: StatefulRuleSessionImpl.java
>
>
> org.drools.jsr94.rules.StatefulRuleSessionImpl currently calls initSession() with constant value true for keepReference. Would be nice if this could be configurable via properties map.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 14:45:56 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 29 Jun 2009 14:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7065) Debugging security
	manager
Message-ID: <14252172.1246301156640.JavaMail.jira@cloud.prod.atl2.jboss.com>

Debugging security manager
--------------------------

                 Key: JBAS-7065
                 URL: https://jira.jboss.org/jira/browse/JBAS-7065
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
            Reporter: David Lloyd
            Assignee: David Lloyd
            Priority: Minor
             Fix For: JBossAS-6.0.0.Alpha1


Develop a security manager which logs security violations, which is surprisingly difficult to make the default security manager do.

If the server log is used, care must be taken to prevent excessive recursion caused by access violations triggered while logging.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 14:45:56 2009
From: jira-events at lists.jboss.org (Tobias Frech (JIRA))
Date: Mon, 29 Jun 2009 14:45:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7066) Unicode characters
 in the install path prevent the server from starting
Message-ID: <23369825.1246301157010.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unicode characters in the install path prevent the server from starting
-----------------------------------------------------------------------

                 Key: JBAS-7066
                 URL: https://jira.jboss.org/jira/browse/JBAS-7066
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA, JBossAS-4.2.3.GA
         Environment: Linux fedora.localdomain 2.6.27.24-78.2.53.fc9.i686 #1 SMP Wed May 20 23:51:32 EDT 2009 i686 i686 i386 GNU/Linux

            Reporter: Tobias Frech


When trying to start JBoss from a path that contains Unicode characters the server fails to boot at all.
JBoss 4.2.3 throws an Exception with "ERROR: it turns out the root cause is not always a runtime exception!" from org.jboss.mx.server.MBeanServerImpl.
JBoss 5.1.0 is a bit better:

20:31:25,313 ERROR [AbstractKernelController] Error installing to Instantiated: name=TransactionManager state=Described
java.lang.ExceptionInInitializerError: java.net.MalformedURLException: no protocol: /home/tobi/Vortr?ge/jboss-5.1.0.GA/server/default/conf/jbossts-properties.xml
	at com.arjuna.ats.arjuna.common.arjPropertyManager.<clinit>(arjPropertyManager.java:70)
	at com.arjuna.ats.jbossatx.jta.TransactionManagerService.<clinit>(TransactionManagerService.java:110)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:149)
...


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jun 29 14:45:57 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 29 Jun 2009 14:45:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7065) Debugging security
	manager
In-Reply-To: <14252172.1246301156640.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2800492.1246301157169.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474237#action_12474237 ] 

David Lloyd commented on JBAS-7065:
-----------------------------------

Maybe add a boot option --security-debug or something like that which automatically sets up the appropriate security manager.

Also, the log messages should include not only a stack trace of the failed operation, but also the stack of codesources that were checked.

> Debugging security manager
> --------------------------
>
>                 Key: JBAS-7065
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7065
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>            Priority: Minor
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Develop a security manager which logs security violations, which is surprisingly difficult to make the default security manager do.
> If the server log is used, care must be taken to prevent excessive recursion caused by access violations triggered while logging.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 18:32:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 29 Jun 2009 18:32:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2149)
 ClassNotFoundException when deserializing a session with accumulate
Message-ID: <14229714.1246314777014.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClassNotFoundException when deserializing a session with accumulate
-------------------------------------------------------------------

                 Key: JBRULES-2149
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2149
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


package org.drools

import java.util.List

global List results

rule "test accumulate serialization"
when
    $total : List() from accumulate( 
         $c : Cheese( type == "brie" ),
         init( java.util.ArrayList s = new java.util.ArrayList(); ),
         action( s.add($c); ),
         reverse( s.remove($c); ),
         result( s ) )
then
    results.add( $total );
end




java.lang.ClassNotFoundException: org.drools.Rule_test_accumulate_serialization_0$Accumulate0
	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:306)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:242)
	at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:585)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
	at org.drools.marshalling.impl.InputMarshaller.readLeftTuple(InputMarshaller.java:540)
	at org.drools.marshalling.impl.InputMarshaller.readFactHandles(InputMarshaller.java:345)
	at org.drools.marshalling.impl.InputMarshaller.readSession(InputMarshaller.java:207)
	at org.drools.marshalling.impl.DefaultMarshaller.unmarshall(DefaultMarshaller.java:75)
	at org.drools.marshalling.impl.DefaultMarshaller.unmarshall(DefaultMarshaller.java:47)
	at org.drools.integrationtests.MarshallingTest.testAccumulateSerialization(MarshallingTest.java:2290)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jun 29 18:36:57 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 29 Jun 2009 18:36:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2149)
 ClassNotFoundException when deserializing a session with accumulate
In-Reply-To: <14229714.1246314777014.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4563122.1246315017009.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2149.
----------------------------------

    Resolution: Done


> ClassNotFoundException when deserializing a session with accumulate
> -------------------------------------------------------------------
>
>                 Key: JBRULES-2149
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2149
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> package org.drools
> import java.util.List
> global List results
> rule "test accumulate serialization"
> when
>     $total : List() from accumulate( 
>          $c : Cheese( type == "brie" ),
>          init( java.util.ArrayList s = new java.util.ArrayList(); ),
>          action( s.add($c); ),
>          reverse( s.remove($c); ),
>          result( s ) )
> then
>     results.add( $total );
> end
> java.lang.ClassNotFoundException: org.drools.Rule_test_accumulate_serialization_0$Accumulate0
> 	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:306)
> 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:242)
> 	at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:585)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
> 	at org.drools.marshalling.impl.InputMarshaller.readLeftTuple(InputMarshaller.java:540)
> 	at org.drools.marshalling.impl.InputMarshaller.readFactHandles(InputMarshaller.java:345)
> 	at org.drools.marshalling.impl.InputMarshaller.readSession(InputMarshaller.java:207)
> 	at org.drools.marshalling.impl.DefaultMarshaller.unmarshall(DefaultMarshaller.java:75)
> 	at org.drools.marshalling.impl.DefaultMarshaller.unmarshall(DefaultMarshaller.java:47)
> 	at org.drools.integrationtests.MarshallingTest.testAccumulateSerialization(MarshallingTest.java:2290)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at junit.framework.TestCase.runTest(TestCase.java:154)
> 	at junit.framework.TestCase.runBare(TestCase.java:127)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 08:58:32 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 30 Jun 2009 08:58:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-99) Track component
	updates
Message-ID: <1859063348.1246366712646.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Track component updates
-----------------------

                 Key: JBJCA-99
                 URL: https://jira.jboss.org/jira/browse/JBJCA-99
             Project: JBoss JCA
          Issue Type: Task
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Track component updates for 1.0.0.Alpha2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 16:46:31 2009
From: jira-events at lists.jboss.org (Brian Dill (JIRA))
Date: Tue, 30 Jun 2009 16:46:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-116) Support for SQL
 Server 2.0 driver (JDBC 4.0)
Message-ID: <1361605096.1246394791395.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Support for SQL Server 2.0 driver (JDBC 4.0)
--------------------------------------------

                 Key: HIBERNATE-116
                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-116
             Project: Hibernate
          Issue Type: Feature Request
            Reporter: Brian Dill
            Assignee: Steve Ebersole




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 17:30:31 2009
From: jira-events at lists.jboss.org (Brian Dill (JIRA))
Date: Tue, 30 Jun 2009 17:30:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (HIBERNATE-116) Support for SQL
 Server 2.0 driver (JDBC 4.0)
Message-ID: <1122814292.1246397431380.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/HIBERNATE-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Dill deleted HIBERNATE-116:
---------------------------------


> Support for SQL Server 2.0 driver (JDBC 4.0)
> --------------------------------------------
>
>                 Key: HIBERNATE-116
>                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-116
>             Project: Hibernate
>          Issue Type: Feature Request
>            Reporter: Brian Dill
>            Assignee: Steve Ebersole
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 11:51:08 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 30 Jun 2009 11:51:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2151) Parser exceptions
Message-ID: <1492226254.1246377068806.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Parser exceptions
-----------------

                 Key: JBRULES-2151
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2151
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.1.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


Parser errors that raise the  "Contact the development team" message.

=================
a similar "contact-developers-bug" occurs when you write an empty not CE:
   not( )
=================



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 06:17:28 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 30 Jun 2009 06:17:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1005) TCPGOSSIP / TCP
 combination fails to find any members
Message-ID: <1192163503.1246357048948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

TCPGOSSIP / TCP combination fails to find any members
-----------------------------------------------------

                 Key: JGRP-1005
                 URL: https://jira.jboss.org/jira/browse/JGRP-1005
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


The TCPGOSSIP:TCP combination doesn't find an initial membership. The issue is in TCPGOSSIP, where an initial lookup doesn't return the physical addrs associated with logical addrs.

Use Draw with JGroups/conf/tcpgossip.xml to reproduce

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 12:36:08 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 30 Jun 2009 12:36:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-99) Track component
	updates
In-Reply-To: <1859063348.1246366712646.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1768762605.1246379768683.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-99:
---------------------------------

    Component/s: Build


> Track component updates
> -----------------------
>
>                 Key: JBJCA-99
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-99
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Track component updates for 1.0.0.Alpha2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 04:06:28 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 30 Jun 2009 04:06:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7063) Upgrade EJB3 to
	1.1.8
In-Reply-To: <31881366.1246284776868.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1553539392.1246349188882.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-7063.
--------------------------------

    Resolution: Done


Done in r90686.

> Upgrade EJB3 to 1.1.8
> ---------------------
>
>                 Key: JBAS-7063
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7063
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Upgrade to the latest released EJB3 1.1.8 version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 04:06:28 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 30 Jun 2009 04:06:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7061) Upgrade EJB3 to
	1.1.8
In-Reply-To: <15406494.1246284658866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1129509323.1246349188954.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-7061.
--------------------------------

    Resolution: Done


> Upgrade EJB3 to 1.1.8
> ---------------------
>
>                 Key: JBAS-7061
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7061
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Upgrade to the latest released EJB3 1.1.8 version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 13:32:31 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 30 Jun 2009 13:32:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-91) SerialVersionUID test
 detecting mismatch with org.jboss.managed.plugins.ManagedObjectImpl
Message-ID: <2047708221.1246383151330.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SerialVersionUID test detecting mismatch with org.jboss.managed.plugins.ManagedObjectImpl
-----------------------------------------------------------------------------------------

                 Key: JBMAN-91
                 URL: https://jira.jboss.org/jira/browse/JBMAN-91
             Project: JBoss Managed
          Issue Type: Bug
          Components: general
            Reporter: Shelly McGowan
            Assignee: Scott M Stark
             Fix For: JBossMan.2.1.1.GA 


Since 2.1.1.CR1 release, JBoss AS integration testsuite showing this failure when compariing serialVer UIDs to 500 and 501:
FAIL: serialVersionUID error for org.jboss.managed.plugins.ManagedObjectImpl, 500 2, current: 3
FAIL: serialVersionUID error for org.jboss.managed.plugins.ManagedObjectImpl, 501 2, current: 3

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 11:53:08 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 30 Jun 2009 11:53:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2151) Parser exceptions
In-Reply-To: <1492226254.1246377068806.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <55726961.1246377188920.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli updated JBRULES-2151:
-----------------------------------

    Attachment: droolError.GIF


> Parser exceptions
> -----------------
>
>                 Key: JBRULES-2151
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2151
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>         Attachments: droolError.GIF
>
>
> Parser errors that raise the  "Contact the development team" message.
> =================
> a similar "contact-developers-bug" occurs when you write an empty not CE:
>    not( )
> =================

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 17:44:31 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 30 Jun 2009 17:44:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7067) Give some context to
 failed creation of WebResourcePermission
Message-ID: <1698673831.1246398271397.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Give some context to failed creation of WebResourcePermission
-------------------------------------------------------------

                 Key: JBAS-7067
                 URL: https://jira.jboss.org/jira/browse/JBAS-7067
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


The following exception: 

Caused by: java.lang.IllegalArgumentException: illegal HTTP method
	at javax.security.jacc.HttpMethodSpec.makeMethodSet(HttpMethodSpec.java:100)
	at javax.security.jacc.HttpMethodSpec.getMethodSet(HttpMethodSpec.java:74)
	at javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:137)
	at org.jboss.web.WebPermissionMapping.createPermissions(WebPermissionMapping.java:220)

...could give the developer a better indication of what went wrong.  Wrap and provide this context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 20:03:31 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 30 Jun 2009 20:03:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2152)
 KnowledgeAgentConfiguration -
 allow for property "drools.agent.newInstance" to be set to false
Message-ID: <1223905269.1246406611567.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Neale reassigned JBRULES-2152:
--------------------------------------

    Assignee: Mark Proctor  (was: Michael Neale)


Mark - can you confirm that you can set this in a properties file but not the change set - and that is the way it should be? 

> KnowledgeAgentConfiguration - allow for property "drools.agent.newInstance" to be set to false
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2152
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2152
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Tihomir Surdilovic
>            Assignee: Mark Proctor
>
> Currently drools.agent.newInstance is hardcoded to true. we need to be able to set it to false as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 20:03:31 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 30 Jun 2009 20:03:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2152)
 KnowledgeAgentConfiguration
 - allow for property "drools.agent.newInstance" to be set to false
Message-ID: <1823175586.1246406611407.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474372#action_12474372 ] 

Michael Neale commented on JBRULES-2152:
----------------------------------------

This might not be an issue - you can set this in the KA configuration *properties*, which are global to all KAs - but not on a per changeset basis. 

> KnowledgeAgentConfiguration - allow for property "drools.agent.newInstance" to be set to false
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2152
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2152
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Tihomir Surdilovic
>            Assignee: Michael Neale
>
> Currently drools.agent.newInstance is hardcoded to true. we need to be able to set it to false as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 19:48:31 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 30 Jun 2009 19:48:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBRULES-2152)
 KnowledgeAgentConfiguration -
 allow for property "drools.agent.newInstance" to be set to false
Message-ID: <2005828456.1246405711311.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Neale moved GUVNOR-376 to JBRULES-2152:
-----------------------------------------------

              Project: JBoss Drools  (was: Guvnor)
                  Key: JBRULES-2152  (was: GUVNOR-376)
    Affects Version/s: 5.0.1.FINAL
                           (was: drools-5.0.1.FINAL)


> KnowledgeAgentConfiguration - allow for property "drools.agent.newInstance" to be set to false
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2152
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2152
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Tihomir Surdilovic
>            Assignee: Michael Neale
>
> Currently drools.agent.newInstance is hardcoded to true. we need to be able to set it to false as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 06:26:28 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 30 Jun 2009 06:26:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1005) TCPGOSSIP / TCP
 combination fails to find any members
In-Reply-To: <1192163503.1246357048948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <590839785.1246357588960.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474266#action_12474266 ] 

Bela Ban commented on JGRP-1005:
--------------------------------

That's because the GossipRouter doesn't maintain bindings between logical and physical addrs. Actually, it is probably sufficient to simply return a list of *physical* addresses, similar to TCPPING.

> TCPGOSSIP / TCP combination fails to find any members
> -----------------------------------------------------
>
>                 Key: JGRP-1005
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1005
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> The TCPGOSSIP:TCP combination doesn't find an initial membership. The issue is in TCPGOSSIP, where an initial lookup doesn't return the physical addrs associated with logical addrs.
> Use Draw with JGroups/conf/tcpgossip.xml to reproduce

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 13:49:31 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 30 Jun 2009 13:49:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-6773)
 org.jboss.test.jmx.test.UndeployBrokenPackageUnitTestCase
In-Reply-To: <11736314.1239664702380.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1339481216.1246384171285.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reopened JBAS-6773:
----------------------------------



This issue is now seen in trunk testsuite.  Reopening to track.

> org.jboss.test.jmx.test.UndeployBrokenPackageUnitTestCase
> ---------------------------------------------------------
>
>                 Key: JBAS-6773
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6773
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: hs_err_pid16939.log
>
>
> JBoss-AS-5.1.x-TestSuite-sun15-sun16 and JBoss-AS-5.1.x-TestSuite-sun16-sun16 are not completing due to a Sun JVM crash which occurs during the execution of this test case.  The same issue was seen in 5.0.0.GA.  See linked issue for the discussion and resolution.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 13:49:31 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 30 Jun 2009 13:49:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6773)
 org.jboss.test.jmx.test.UndeployBrokenPackageUnitTestCase
In-Reply-To: <11736314.1239664702380.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <828727184.1246384171381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6773:
---------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
                       (was: JBossAS-5.1.0.GA)


> org.jboss.test.jmx.test.UndeployBrokenPackageUnitTestCase
> ---------------------------------------------------------
>
>                 Key: JBAS-6773
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6773
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>         Attachments: hs_err_pid16939.log
>
>
> JBoss-AS-5.1.x-TestSuite-sun15-sun16 and JBoss-AS-5.1.x-TestSuite-sun16-sun16 are not completing due to a Sun JVM crash which occurs during the execution of this test case.  The same issue was seen in 5.0.0.GA.  See linked issue for the discussion and resolution.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 06:33:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 30 Jun 2009 06:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1666) Add
 "messageCount" attribute on Address MBean
In-Reply-To: <18851986.1245825537257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1209930346.1246358009136.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1666:
---------------------------------

    Fix Version/s: 2.0.0


> Add "messageCount" attribute on Address MBean
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1666
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1666
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Value shown in "messageCount" attribute of a queue MBean does not include the number of messages that are paged. This is because messages are paged to disk  before they are routed in the postoffice. So, for the user to be able to find the total number of messages that are added to a queue, Tim suggested that, we add a "messageCount" attribute to the Address MBean. That would indicate how many messages are paged for a particular destination address.  Please refer http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157325 for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 11:58:08 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 30 Jun 2009 11:58:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-202) BeansDeployer
 cannot be recycled
Message-ID: <1676631077.1246377488627.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

BeansDeployer cannot be recycled
--------------------------------

                 Key: JBDEPLOY-202
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-202
             Project: JBoss Deployers
          Issue Type: Bug
          Components: classloading
    Affects Versions: JBDEPLOY-2.0.5.GA
            Reporter: Thomas Diesler
            Assignee: Thomas Diesler
             Fix For:  JBDEPLOY-2.2.x


Caused by: java.lang.ClassCastException
at java.lang.Class.cast(Class.java:2990)
at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:215)
at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132)
at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118)
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:239)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:330)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 17:58:31 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 30 Jun 2009 17:58:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7067) Give some context
 to failed creation of WebResourcePermission
In-Reply-To: <1698673831.1246398271397.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <187352341.1246399111373.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-7067.
---------------------------------------

    Resolution: Done


> Give some context to failed creation of WebResourcePermission
> -------------------------------------------------------------
>
>                 Key: JBAS-7067
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7067
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The following exception: 
> Caused by: java.lang.IllegalArgumentException: illegal HTTP method
> 	at javax.security.jacc.HttpMethodSpec.makeMethodSet(HttpMethodSpec.java:100)
> 	at javax.security.jacc.HttpMethodSpec.getMethodSet(HttpMethodSpec.java:74)
> 	at javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:137)
> 	at org.jboss.web.WebPermissionMapping.createPermissions(WebPermissionMapping.java:220)
> ...could give the developer a better indication of what went wrong.  Wrap and provide this context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 17:46:31 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 30 Jun 2009 17:46:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7067) Give some context
 to failed creation of WebResourcePermission
In-Reply-To: <1698673831.1246398271397.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1704944178.1246398391281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474366#action_12474366 ] 

Andrew Lee Rubinger commented on JBAS-7067:
-------------------------------------------

Now wrapped in:

Caused by: java.lang.IllegalArgumentException: Could not create resource permission with pattern "/restricted/*" and methods: !GET,POST
   at org.jboss.web.WebPermissionMapping.createPermissions(WebPermissionMapping.java:229)

> Give some context to failed creation of WebResourcePermission
> -------------------------------------------------------------
>
>                 Key: JBAS-7067
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7067
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The following exception: 
> Caused by: java.lang.IllegalArgumentException: illegal HTTP method
> 	at javax.security.jacc.HttpMethodSpec.makeMethodSet(HttpMethodSpec.java:100)
> 	at javax.security.jacc.HttpMethodSpec.getMethodSet(HttpMethodSpec.java:74)
> 	at javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:137)
> 	at org.jboss.web.WebPermissionMapping.createPermissions(WebPermissionMapping.java:220)
> ...could give the developer a better indication of what went wrong.  Wrap and provide this context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 13:28:31 2009
From: jira-events at lists.jboss.org (Art Plata (JIRA))
Date: Tue, 30 Jun 2009 13:28:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (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: <1760479310.1246382911558.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474351#action_12474351 ] 

Art Plata commented on JBMESSAGING-1661:
----------------------------------------

I got this working by copying the source for Bridge.java in 1.4.4, to 1.4.3. The Remote cluster receives messages fine, but now we're running into an issue with messages getting stuck when we try to test fail-over on the remote cluster. This looks like a separate issue. Should i open a new bug? 

> 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://jira.jboss.org/jira/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: Howard Gao
>             Fix For: 1.4.5.GA
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 16:08:31 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 30 Jun 2009 16:08:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-202) BeansDeployer
 cannot be recycled
In-Reply-To: <1676631077.1246377488627.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1611067409.1246392511324.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474364#action_12474364 ] 

Thomas Diesler commented on JBDEPLOY-202:
-----------------------------------------

Fixed in 2.0.5.SP1

Still affects 2.0.6.GA, 2.0.7.GA, 2.0.8.GA

Changes are not ported to Branch_2_0 because this branch uses JBossXBHelper from jbossxb-2.0.1.GA. 
The issue with the JBossXBHelper needs to be fixed there - to be discussed.

Also not ported to trunk for the same reason.

> BeansDeployer cannot be recycled
> --------------------------------
>
>                 Key: JBDEPLOY-202
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-202
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: classloading
>    Affects Versions: JBDEPLOY-2.0.5.GA
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For:  JBDEPLOY-2.2.x
>
>
> Caused by: java.lang.ClassCastException
> at java.lang.Class.cast(Class.java:2990)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:215)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:239)
> at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:330)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 11:05:08 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Tue, 30 Jun 2009 11:05:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2150) stream mode
 requires DroolsStreamUtils
Message-ID: <114326829.1246374308757.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

stream mode requires DroolsStreamUtils
--------------------------------------

                 Key: JBRULES-2150
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2150
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core (fusion)
    Affects Versions: 5.0.1.FINAL
            Reporter: Jaroslaw Kijanowski
            Assignee: Edson Tirelli
         Attachments: cep.drl, CEPTest.java, Sensor.java

I'm using sliding windows (hence stream mode).
Here's my rule:

rule 'r'
when
Number( dv:doubleValue > 1 ) from accumulate(
        Sensor( $v : value ) over window:length( 2 ),
        average( $v ) )
then
    System.out.println(dv);
end

Here's my class:

++++++++++++++++++++++++++++++++++++++++++++++
public class CEPTest {
  public static void main(String[] args) throws Exception {
.
.
.
    kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
    KnowledgeBase kbase2 = (KnowledgeBase) DroolsStreamUtils.streamIn(DroolsStreamUtils.streamOut(kbase), null);

    final StatefulKnowledgeSession ksession = kbase2.newStatefulKnowledgeSession();

    System.out.println("T1");
    ksession.insert(new Sensor(1.0));
    ksession.fireAllRules();

    System.out.println("T2");
    ksession.insert(new Sensor(2.0));
    ksession.fireAllRules();

    System.out.println("T3");
    ksession.insert(new Sensor(3.0));
    ksession.fireAllRules();

    ksession.dispose();
  }
}
++++++++++++++++++++++++++++++++++++++++++++++
The output is (as expected):
+++++++++++++++
T1
T2
1.5
T3
2.5
+++++++++++++++

I'm wondering why I have to use DroolsStreamUtils to get a knowledge base? When I use kbase (which didn't went through DroolsStreamUtils) instead of kbase2 to create a new session, the output will be:
+++++++++++++++
T1
T2
2.0
T3
3.0
+++++++++++++++ 

Attaching all 3 files needed to reproduce - rule, model and test.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 14:10:31 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 30 Jun 2009 14:10:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1804) Logical
 insertion lingers
 after the rule that inserted it no longer supports it (with testcase patch)
In-Reply-To: <7576319.1224262460882.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1857414143.1246385431739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474354#action_12474354 ] 

Geoffrey De Smet commented on JBRULES-1804:
-------------------------------------------

Laurent on the mailing list ran into this one too.

It happens when you calculate the weight of a constraintoccurrence based on property of a fact and that property isn't stable (although the working memory has been notified that the fact was changes, so it property could have changed)

> Logical insertion lingers after the rule that inserted it no longer supports it (with testcase patch)
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1804
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1804
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions:  5.0.0.M2
>            Reporter: Geoffrey De Smet
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.1.0.M1
>
>
> This one got me headscratching for a while, untill I realized what the problem is.
> Tim reported on the mailing list he ran into it to.
> I've commmited a testcase in subversion, in TruthMaintenanceTest, called
>    disabled_testLogicalInsertionsModifySameRuleGivesDifferentLogicalInsertion
> Remove the "disabled_" to enable it and try it out.
> Here's what happens in the testcase:
> 3 sensors with tempature 100, 200 and 200 are inserted.
> There's a rule which logically inserts all encountered tempatures, so 100 and 200.
> Then the first sensor modifies to a tempature of 150.
> As it turns out, the encoutered tempatures should be 150 and 200 now, but instead it's 100, 150 and 200.
> Even though there is no sensor that has a tempature of 100.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 11:58:08 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 30 Jun 2009 11:58:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-202) BeansDeployer
 cannot be recycled
In-Reply-To: <1676631077.1246377488627.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <64104868.1246377488778.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474330#action_12474330 ] 

Thomas Diesler commented on JBDEPLOY-202:
-----------------------------------------

The underlying issue is that BeansDeployer uses an JBossXBDeployerHelper

BeansDeployer -> SchemaResolverDeployer -> JBossXBDeployer

The JBossXBDeployerHelper uses

   private static DefaultSchemaResolver resolver = (DefaultSchemaResolver)SingletonSchemaResolverFactory.getInstance().getSchemaBindingResolver();

which internally caches the classes.

>From what I can see SingletonSchemaResolverFactory is evil and cannot be used in an OSGi environment.


> BeansDeployer cannot be recycled
> --------------------------------
>
>                 Key: JBDEPLOY-202
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-202
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: classloading
>    Affects Versions: JBDEPLOY-2.0.5.GA
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For:  JBDEPLOY-2.2.x
>
>
> Caused by: java.lang.ClassCastException
> at java.lang.Class.cast(Class.java:2990)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:215)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:239)
> at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:330)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 15:12:31 2009
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Tue, 30 Jun 2009 15:12:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-549) ConnectionTable:
 spurious Connection instances on concurrent connects
In-Reply-To: <10580511.1183710592881.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1033076656.1246389151306.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474359#action_12474359 ] 

Dennis Reed commented on JGRP-549:
----------------------------------

Backported another change to the 2.4.x branch to short-circuit local messages, to fix a regression issue.

> ConnectionTable: spurious Connection instances on concurrent connects
> ---------------------------------------------------------------------
>
>                 Key: JGRP-549
>                 URL: https://jira.jboss.org/jira/browse/JGRP-549
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.4.7, 2.6
>
>
> If we have members A and B, and they don't yet have connections to each other, and start sending messages to each other at the exact same time, then we run into the following scenario:
> - A attempts to connect to B (new Socket())
> - B attempts to connect to A
> - A accepts B's connection and adds an entry for B into its table
> - B adds an entry for A into its table
> - B gets the accept() from A, but doesn't add the new Connection into its table because there is already a Connection. This leads to a spurious Connection object, which will only be closed and garbage collected once A or B leaves the cluster
> - We used to close Connections which were already in the table, but this lead to ping-pong effects where concurrent initial senders always closed each others connections
> - Even worse: a new Socket() always creates a new Connection object and places it into the table, *regardless* of whether a Connection for a given destination already exists or not !
> GOAL:
> #1 Have only 1 TCP connection between any 2 members
> #2 Establish a handshaking mechanism, to avoid spurious connections
> SOLUTION:
> - When A establishes a connection to B, A needs to get agreement from B first (and vice versa)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 11:05:08 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Tue, 30 Jun 2009 11:05:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2150) stream mode
 requires DroolsStreamUtils
In-Reply-To: <114326829.1246374308757.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <793890624.1246374308917.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jaroslaw Kijanowski updated JBRULES-2150:
-----------------------------------------

    Attachment: Sensor.java
                CEPTest.java
                cep.drl


> stream mode requires DroolsStreamUtils
> --------------------------------------
>
>                 Key: JBRULES-2150
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2150
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Jaroslaw Kijanowski
>            Assignee: Edson Tirelli
>         Attachments: cep.drl, CEPTest.java, Sensor.java
>
>
> I'm using sliding windows (hence stream mode).
> Here's my rule:
> rule 'r'
> when
> Number( dv:doubleValue > 1 ) from accumulate(
>         Sensor( $v : value ) over window:length( 2 ),
>         average( $v ) )
> then
>     System.out.println(dv);
> end
> Here's my class:
> ++++++++++++++++++++++++++++++++++++++++++++++
> public class CEPTest {
>   public static void main(String[] args) throws Exception {
> .
> .
> .
>     kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
>     KnowledgeBase kbase2 = (KnowledgeBase) DroolsStreamUtils.streamIn(DroolsStreamUtils.streamOut(kbase), null);
>     final StatefulKnowledgeSession ksession = kbase2.newStatefulKnowledgeSession();
>     System.out.println("T1");
>     ksession.insert(new Sensor(1.0));
>     ksession.fireAllRules();
>     System.out.println("T2");
>     ksession.insert(new Sensor(2.0));
>     ksession.fireAllRules();
>     System.out.println("T3");
>     ksession.insert(new Sensor(3.0));
>     ksession.fireAllRules();
>     ksession.dispose();
>   }
> }
> ++++++++++++++++++++++++++++++++++++++++++++++
> The output is (as expected):
> +++++++++++++++
> T1
> T2
> 1.5
> T3
> 2.5
> +++++++++++++++
> I'm wondering why I have to use DroolsStreamUtils to get a knowledge base? When I use kbase (which didn't went through DroolsStreamUtils) instead of kbase2 to create a new session, the output will be:
> +++++++++++++++
> T1
> T2
> 2.0
> T3
> 3.0
> +++++++++++++++ 
> Attaching all 3 files needed to reproduce - rule, model and test.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jun 30 11:07:09 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Tue, 30 Jun 2009 11:07:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-446)
 bean-deployer xsds don't contain web references
In-Reply-To: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <252015958.1246374429102.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMICROCONT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474318#action_12474318 ] 

Wolfgang Knauf commented on JBMICROCONT-446:
--------------------------------------------

The "rcase-RecurseLax.2" error is also discussed here:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=145209
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223327

> bean-deployer xsds don't contain web references
> -----------------------------------------------
>
>                 Key: JBMICROCONT-446
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Wolfgang Knauf
>            Assignee: Kabir Khan
>
> bean-deployer_2_0.xsd:
>    <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
> =>should point. 
>    <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">
> The comment for a sample instance should also contain a schema location attribute:
>          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xmlns="urn:jboss:bean-deployer:2.0"
>             xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">
> ==================
> bean-deployer_1_0.xsd:
> The comment for a sample instance should point to the web schema location:
>          <deployment
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
>             xmlns="urn:jboss:bean-deployer">
> =================
> policy_1_0.xsd:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
> should be:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>
> =================
> bean-deployer_2_0.xsd raises validation errors in Eclipse:
> -rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
> -src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
> According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


